2013/8/30 Tom Lane <tgl@sss.pgh.pa.us>:
> Josh Berkus <josh@agliodbs.com> writes:
>> On 08/30/2013 12:43 PM, Tom Lane wrote:
>>> In short, "we can check some check-box" is a really, really bad reason
>>> to accept a security-related feature. If we're going to put up with
>>> all the downsides of RLS, I want the end result to be something that's
>>> actually secure, not something that gives the illusion of security.
>
>> Can you be more explicit about "all the downsides of RLS"? I was just
>> looking over the patch, which is less than 5000 lines. While it's not
>> small, we have larger patches in the CF. So what's the specific
>> downsides of this?
>
> I think it's going to be an ongoing maintenance headache and an endless
> source of security bugs, even disregarding covert-channel issues. I have
> pretty much zero faith in the planner changes, in particular, and would
> still not have a lot if they were adequately documented, which they
> absolutely are not. The whole thing depends on nowhere-clearly-stated
> assumptions that plan-time transformations will never allow an RLS check
> to be bypassed. I foresee future planner work breaking this in
> non-obvious ways on a regular basis (even granting the assumption that
> it's bulletproof today, which is at best unproven).
>
In general, we will adopt / enhance features as long as PostgreSQL runs
with evolution. It can never be free from bugs or maintenance, regardless
of its nature.
Later half seems to me a bit unfair because any features may conflict
with some future works, not only RLS. Also, if you have some tangible
planner enhancement plan, could you inform us which plan shall be
in progress? At least, it is impossible to adjust my implementation
because of abstract concern towards future conflict.
Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>
