Josh Berkus <j...@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).
> The reason I brought up multi-tenant applications ("MTA"), BTW, is that
> this is the other major potential utility of RLS, and for such users the
> covert channel limitations are acceptable (as long as we publish them).
[ shrug... ] You might've noticed I work for a multi-tenant shop now.
I'm still not excited about this.
> That is, if RLS is your *second* level of defense, instead of your
> primary defense, covert channels are not a make-or-break issue. It just
> has to be better than what we had before.
Yeah, that's a fair point. I'm just not convinced that it's enough better
to justify the maintenance burden we'll be taking on. I'm not thrilled
about the "every bug is a security bug" angle, either.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
