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.
> And right now, I do not believe we can get past the illusion stage,
> ever (certainly not in a release or two).
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?
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).
That is, for a "thing-as-a-service" application, users are not assumed
to have unlimited access to the SQL command line anyway; RLS is employed
just to limit the damage they can do if they get access, and to limit
the disclosure if some app programmer makes a mistake.
Right now, the primary tool for doing row filtering for MTA is Veil,
which has numerous and well-known limitations. If RLS has fewer
limitations, or is easier to deploy, maintain, and/or understand, then
it's a valuable feature for that user base, even if it doesn't address
the covert channels we've brought up at all.
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.
Note that I have NOT done an evaluation of Veil vs. RLS for MTA at this
point. I'm hoping someone else will ;-)
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
