Karl, * Karl Czajkowski (karlcz@xxxxxxx) 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
Attachment:
signature.asc
Description: Digital signature
