Karl,
* Karl Czajkowski (karlcz@isi.edu) wrote:
> Ideally, I'd be able to write a policy that has conditions for each
> category of operation:
>
> POLICY FOR SELECT WITH expr1
> POLICY FOR INSERT WITH expr2
> POLICY FOR DELETE WITH expr3
> POLICY FOR UPDATE WITH expr4
It's possible to have such policies for a table today. These would be
independent policies and not all one policy, but I don't see that as
making a practical difference here.
> where expr1 would always be used to decide whether the current tuple
> is visible to the query engine, expr2 would always be used to validate
> new rows, expr3 would always be used to authorize row deletion, and
> expr4 would be able to authorize row replacement using NEW and OLD
> value comparisons.
Any UPDATE which requires SELECT rights on the table will require expr1
to pass AND expr4 (the UPDATE's USING clause) to pass. This is modeled
directly off of our existing GRANT/ACL system. The same is true for the
other commands. Note that we explicitly want an independent USING
clause for expr4 as you may wish to reduce the set of rows which may be
UPDATE'd to be less than the set which are visible via SELECT.
I anticipate adding the ability to have "restrictive" policies also, in
the future.
> An actual SQL UPDATE for a row visible according to expr1 could be
> authorized if expr4 allows it *or* if expr3 and expr2 would allow a
> DELETE followed by INSERT. Where this becomes interesting is when a
> session context with insufficient privilege to do the DELETE and
> INSERT sequence is still allowed to do the UPDATE because their
> request fits the narrower confines of the expr4 policy.
While allowing an UPDATE if a DELETE/INSERT would be allowed is an
interesting idea, it strikes me as being more complicated to explain and
justify to users than any value it would add.
Thanks!
Stephen
