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 -
AnON 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.
best regards,
Florian Pflug