Date: Sun, 1 Sep 2013 16:06:27 +0200
From: Andres Freund <andres@2ndquadrant.com>
To: Heikki Linnakangas <hlinnakangas@vmware.com>
Cc: Josh Berkus <josh@agliodbs.com>, Tom Lane <tgl@sss.pgh.pa.us>,
 Stephen Frost <sfrost@snowman.net>,
 Kohei KaiGai <kaigai@kaigai.gr.jp>, "ktm@rice.edu" <ktm@rice.edu>,
 Alexander Korotkov <aekorotkov@gmail.com>,
 Oleg Bartunov <obartunov@gmail.com>, Greg Smith <greg@2ndquadrant.com>,
 PgHacker <pgsql-hackers@postgresql.org>
Subject: Re: [v9.4] row level security
Message-ID: <20130901140627.GA21721@awork2.anarazel.de>
References: 
 <WM!685df689dd4d8f8c5349d5ef7b8e285db1e99ea32d22ab5d35f3981c29eac19dbd725c9b5e0227def9d782de274d1354!@asav-3.01.com>
 <521F7DFB.8060602@agliodbs.com>
 <CADyhKSW_o2nVWFytdTY84DUXZSuZkD_EtY2d8wAjR18UruOXYQ@mail.gmail.com>
 <WM!fb94ecb91cd381e69d8e4773d3810f48e4e0ef000525cc806c4ee509f215ce1a39c8c2a1c3ffde72ba2ddb1a07ebcdc9!@asav-2.01.com>
 <5220D832.7090104@agliodbs.com>
 <20130830192729.GO2706@tamriel.snowman.net>
 <16798.1377891794@sss.pgh.pa.us>
 <WM!20618a88b943d2d51dde90beb5cb85eea4bacc1ee65b4bb73872fafa086f76aee8b9caf4e1c1a7e5865845cf76661b1b!@asav-3.01.com>
 <5220F928.7040503@agliodbs.com> <5223436B.1070406@vmware.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5223436B.1070406@vmware.com>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On 2013-09-01 16:38:51 +0300, Heikki Linnakangas wrote:
> On 30.08.2013 22:57, Josh Berkus wrote:
> >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 ;-)
> 
> I'd also like to hear how Veil differs from RLS. From what I've understood
> this far, they are the same in terms of what you can and cannot do.
> 
> To phrase it differently: We already have RLS. It's shipped as an extension
> called Veil. Now please explain what's wrong with that statement, if
> anything.

I don't think veil really is an argument for much in this discussion. I
don't know who in this discussion has used it, I have. Admittedly a good
bit ago, 8.2, 8.3 days I think. There hasn't been much fundamental
development since though, if my quick look is right.
Veil gives you a rather low level toolbox for developing an RLS and
you're left with a *huge* amount of work needed ontop.
It basically gives you a bunch of new datatypes (sets, bitmaps, ranges) and
provides some support for sharing variables across backends (shared
memory). That's nearly it.

Greetings,

Andres Freund

-- 
 Andres Freund	                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers