2012/5/24 Florian Pflug <fgp@phlo.org>:
> On May24, 2012, at 12:43 , Kohei KaiGai wrote:
>> The case of INSERT / DELETE are simple; All we need to apply is
>> checks on either new or old tuples.
>>
>> In case of UPDATE, we need to check on the old tuple whether use can
>> see, and on the new tuple whether use can store them.
>> Indeed, these are different checks, however, it seems like a black hole
>> if the new tuple is allowed to write but no reader privileges.
>> I expect most use cases choose same policy on reader timing and
>> writer times at UPDATE statement.
>
> I don't think preventing block holes is sensible here - it might,
> in fact, be *just* what the user wants.
>
> Imagine a messaging system. A reasonable RLS policy would be to allow
> a user to see messages addressed to him. Yet you wouldn't want to prevent
> her from creating messages to other people - cause what good is a messaging
> system that only allows you to send messages to yourself. What you
> probably *would* want to do, though, is to check that she did put herself in
> as the sender when she creates a message. And you'd probably wanna forbit
> updates entirely. So you'd have
>
> - A RLS policy that checks current_user = ANY(recipients)
> - An ON INSERT trigger which checks current_user = sender
> - An ON UPDATE trigger which errors out
>
> If RLS policy applies to INSERTEed rows also, how would you do that?
>
> Another example, although in the realm of filesystem permissions, is Mac OS X.
> Per default, every user has a "Drop Box" folder, which anybody can write to, yet
> only the owner can read. This allows you to easily transfer files from one
> user to another without allowing a third party to read it.
>
Indeed, you are right. We have no special reason why to enforce same rules
on both of reader and writer stage on UPDATE statement.
So, the proposed interface might be revised as follows: ALTER TABLE <tblname> ADD SECURITY POLICY
<func_name>(<args>,...) [FOR SELECT | INSERT |
[BEFORE|AFTER] UPDATE |
DELETE];
In case of INSERT or AFTER UPDATE, I assume the check shall be applied
on the tail of before-row triggers.
(*) I don't check whether it conflicts syntax or not yet.
Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>