Re: Row-security writer-side checks proposal - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: Row-security writer-side checks proposal
Date
Msg-id 5278433D.2070606@2ndquadrant.com
Whole thread Raw
In response to Re: Row-security writer-side checks proposal  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Row-security writer-side checks proposal  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 11/04/2013 09:55 PM, Robert Haas wrote:
> I continue to think that this syntax is misguided.  For SELECT and
> DELETE there is only read-side security, and for INSERT there is only
> write-side security, so that's OK as far as it goes, but for UPDATE
> both read-side security and write-side security are possible, and
> there ought to be a way to get one without the other.  This syntax
> won't support that cleanly.

That's what I was thinking earlier too - separate "FOR READ" and "FOR
WRITE" instead.

The reason I came back to insert/update/delete was that it's entirely
reasonable to want to prohibit deletes but permit updates to the same
tuple. Both are writes; both set xmax, it's just that one _replaces_ the
tuple, the other doesn't.

So really, there are four cases:

READ
WRITE INSERT
WRITE UPDATE
WRITE DELETE

> I wonder whether it's worth thinking about the relationship between
> the write-side security contemplated for this feature iand the WITH
> CHECK OPTION syntax that we have for auto-updateable views, which
> serves more or less the same purpose.  I'm not sure that syntax is any
> great shakes, but it's existing precedent of some form and could
> perhaps at least be looked at as a source of inspiration.

I've been thinking about the overlap with WITH CHECK OPTION as well.

> I would generally expect that most people would want either "read side
> security for all commands" or "read and write side security for all
> commands".  I think whatever syntax we come up with this feature ought
> to make each of those things straightforward to get.

but sometimes with different predicates for read and write, i.e. you can
see rows you can't modify or can insert rows / update rows that you
can't see after the change.

Similarly, saying you can update but not delete seems quite reasonable
to me.

On the other hand, we might choose to say "if you want to do things with
that granularity use your own triggers to enforce it" and provide only
READ and WRITE for RLS.

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



pgsql-hackers by date:

Previous
From: Thom Brown
Date:
Subject: Re: List of "binary-compatible" data types
Next
From: Noah Misch
Date:
Subject: Re: pgsql: Remove internal uses of CTimeZone/HasCTZSet.