Re: row security roadmap proposal

On 12/18/2013 01:03 AM, Robert Haas wrote:
> On Mon, Dec 16, 2013 at 3:12 PM, Gregory Smith <gregsmithpgsql(at)gmail(dot)com> wrote:
>> > On 12/16/13 9:36 AM, Craig Ringer wrote:
>>> >>
>>> >> - Finish and commit updatable security barrier views. I've still got a
>>> >> lot of straightening out to do there.
>> >
>> > I don't follow why you've put this part first. It has a lot of new
>> > development and the risks that go along with that, but the POC projects I've
>> > been testing are more interested in the view side issues.
> I don't really see a way that any of this can work without that. To
> be clear, that work is required even just for read-side security.

It's possible to build limited read-side-only security on top of the
existing s.b. views as they stand, with no update support.

You can grant write-only access to the base relations, and require
people to use a different relation name / schema when they want to
access a relation for write vs for read. You can't use RETURNING, and
you can still learn from result rowcounts etc. It's clumsy but usable-ish.

So it works - as long as you're using absolutely 100% read-only access
for users you need to constrain, or you don't mind explicitly referring
to the base table for write operations and not being able to use RETURNING.

I've been looking at write support primarily because I was under the
impression from prior discussion I read that the feature wasn't
considered committable as a read-only feature. If a consensus can be
built that read-only RLS would be acceptable after all, then I'll
happily defer that in favour of the other work items.

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