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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
