Re: Check old and new tuple in row-level policy? - Mailing list pgsql-general

On Dec 18, Stephen Frost modulated:

> 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.
>

Right, I think I understand that. However, my argument was (and
remains) that I think the update conditions need to be able to access
OLD and NEW row values to decide whether the existing row security
context allows the new update content.  This update decision is
inherently different from select, insert, and delete decisions.

I don't think that two separate decisions are sufficient:

   1. OLD row can be updated  (the USING condition?)
   2. NEW row is acceptable (the CHECK condition?)

when considering the row lifecycle as having continuity of identity
and security context.  I think that the second decision needs to have
the option to compare OLD and NEW to decide that the new row is an
acceptable transform of the existing row, preserving whatever identity
and/or security context is important in a particular system of
policies.

As I understand this discussion, you are telling me to just use an
update trigger for this.  I can understand that as a workaround given
the current row-security options, but I do think that this kind of
decision is essential to row-security in realistically complex
applications that allow row mutation.  I don't think it is
particularly esoteric to suggest that the existing row security
context should limit possible future configurations of the row by
different parties.  That effect spans security context, row
identities, and regular non-identifying content.

Right now, it seems like the row-security model assumes the only
security context is an "owner" field carrying a user name and that is
never mutated (perhaps by a column-level privilege).  I think security
context can be richer than that, including more abstract roles,
classes, or attributes and having users be able to mutate that context
but only under the control of row-security policy.  It is not as
simple as the context being system managed only, or open to arbitrary
changes by admins and no change by others. Rather, the current context
may grant certain classes of user the ability to make only certain
coherent changes to that context.

Where mutation is different here is that a set of collaborating
parties can interpret one mutable row as a long-lived resource that
has an ongoing identity (or set of identities) and a coherent series
of row states protected by policy.  Without the ability for the OLD
row to contrain how the NEW row develops in an update policy, we lose
that coherence and have a fugue state for the application, with no
ability to trust the identity of content over time.


Karl