Re: Row-security on updatable s.b. views

On 03/05/2014 05:25 PM, Yeb Havinga wrote:
> Maybe a naive thought, but shouldn't all plans that include a table with
> an RLS clause be invalidated when the session role switches, regardless
> of which users from and to?

Only if the plan is actually accessed when under a different user ID.
Consider SECURITY DEFINER functions; you don't want to flush all cached
plans just because you ran a SECURITY DEFINER function that doesn't even
share any statements with the outer transaction.

Anyway, the same issue remains: how to pass the information "this plan
is user-id specific" from rewriter to planner.

>> I've also got some concerns about the user visible API; I'm not sure it
>> makes sense to set row security policy for row reads per-command in
>> PostgreSQL, since we have the RETURNING clause. Read-side policy should
>> just be "FOR READ".
>
> Hmm but FOR READ would mean new keywords, and SELECT is also a concept
> known to users. I didn't find the api problematic to understand, on the
> contrary.

Would you expect that FOR SELECT also affects rows you can see to
UPDATE, INSERT, or DELETE?

Because that's what it would have to mean, really. Otherwise, you could
just use `UPDATE thetable SET id = id RETURNING *` (or whatever) to read
the rows out if you had UPDATE rights. Or do the same with DELETE.

With RETURNING, it doesn't make much sense for different statements to
have different read access. Can you think of a case where it'd be
reasonable to deny SELECT, but allow someone to see the same rows with
`UPDATE ... RETURNING` ?

> It might be an idea to add the SELECT RLS clause for DML
> queries that contain a RETURNING clause.

That way lies madness: A DML statement that affects *a different set of
rows* depending on whether or not it has a RETURNING clause.

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