Re: Review of Row Level Security - Mailing list pgsql-hackers

2012/12/20 Kevin Grittner <kgrittn@mail.com>:
> Kohei KaiGai wrote:
>
>> If system ensures writer's permission is always equivalent or
>> more restrictive than reader's permission, it also eliminates the
>> problem around asymmetric row-security policy between commands.
>
> I'm not sure we're understanding each other; so far people who
> favor asymmetric read and write predicates for row level security
> have been arguing that people should be able to write tuples that
> they can't read back. Of course you need to be able to read a tuple
> to update it, but the argument is that you should be able to
> configure security so that a role can (for example) update a row to
> set a "sealed" flag, and then no longer have rights to read that
> row (including for purposes of update). You can "give away" data
> which is yours, but you can't then "take it back" if it's not.
>
Hmm, for this example, the right behavior is to check rows with
((row-security of select) AND (row-security of update)) on scan-
stage, but only (row-security of update) is checked on just-before
row updates.
In case of (row-security of select) is "sealed = false", it is not
visible thus not target row of the update, but user can turn on
the flag to make it gone.
Anyway, the row-security to be applied on "scanning-stage" of
source of update/delete needs to be equivalent or more
restrictive than rules on select. However, it might not be needed
to ensure rules being restrictive on "writer-stage".

>> Probably, we can implement it as ((row-security of select) AND
>> (row-security of update)) that ensures "always restrictive
>> row-security policy".
>
> I hadn't been paying a lot of attention to this patch until I saw
> the question about whether a user with a particular role could
> write a row which would then not be visible to that role. I just
> took a look at the patch.
>
> I don't think I like ALTER TABLE as a syntax for row level
> security. How about using existing GRANT syntax but allowing a
> WHERE clause? That seems more natural to me, and it would make it
> easy to apply the same conditions to multiple types of operations
> when desired, but use different expressions when desired.
>
It seems to me this syntax gives an impression that row-security
feature is tightly combined with role-mechanism, even though it
does not need. For example, we can set row-security policy of
primary key is even/odd number, independent from working role.

> Without
> having spent a lot of time pondering it, I think that if row level
> SELECT permissions exist, they would need to be met on the OLD
> tuple to allow DELETE or UPDATE, and UPDATE row level permissions
> would be applied to the NEW tuple.
>
Yes, I agree.

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>