I feel that the fundamental question here is about the semantics of
"row" in row security. The core question is whether UPDATE has a
different semantics with respect to row identity and security context
than a sequence of DELETE, INSERT.
At the moment, the documented solution feels like "tuple security" and
supports an idea of security context encoded into a tuple such that a
policy condition can decide whether its context and data configuration
is consistent with the session context. This makes sense in a pure
relational calculus, but ignores the practical deviation of SQL where
there are mutable records.
I am hoping for "record security" that supports an idea of security
context encoded into a record such that the context in the existing
record can constrain how the update of the record is formed. This
includes policies that might differentiate updates to key versus
non-key fields in the record, deciding in application terms whether
the record has an identity and context that carries forward through
the UPDATE or whether it is merely sugar for a DELETE followed by
INSERT.
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
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.
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.
Karl