On May23, 2012, at 22:12 , Robert Haas wrote:
> Also, suppose that Bob applies an RLS policy to a table, and, later,
> Alice selects from the table. How do we keep Bob from usurping
> Alice's privileges?
That problem isn't restricted to RLW, though. Bob could just as well
have booby-trapped any other SQL object, e.g. could have added
bobs_malicious_function() to a view Alice selects from, or attached
it as a trigger to a table Alice inserts to.
It would be nice if there was (optional) protection against these
kinds of attacks, but it's not really something that RLS should be
burdened with.
BTW, I've wondered in the past how tight our protection against some
trying to take over the postgres role during pg_dump is. On the surface,
it seems that we're safe because pg_dump doesn't invoke user-defined
functions except output functions (which require superuser privileges
to modify). But that's not exactly a solid line of defense...
>> If we also apply the security policy to newer version of tuples on
>> update and insert, one idea is to inject a before-row-(update|insert)
>> trigger to check whether it satisfies the security policy.
>> For same reason, the trigger should be executed at the end of
>> trigger chain.
>
> It's not clear to me that there is any need for built-in server
> functionality here. If the table owner wants to enforce some sort of
> policy regarding INSERT or UPDATE or DELETE, they can already do that
> today just by attaching a trigger to the table. And they can enforce
> whatever policy they like that way. Before designing any new
> mechanism, what's wrong with the existing one?
Yeah, applying the security policy to the new row (for UPDATES
and INSERTS) seems weird - the policy determines what you can see,
not what you can store, which might be two different things.
But the security policy should still apply to the old rows, i.e.
you shouldn't be after to UPDATE or DELETE rows you cannot see, no?
best regards,
Florian Pflug