On 06/03/14 02:56, Craig Ringer wrote:
On 03/06/2014 04:56 AM, Yeb Havinga wrote:

If you state it like that, it sounds like a POLA violation. But the
complete story is: "A user is allowed to UPDATE a set of rows from a
table that is not a subsect of the set of rows he can SELECT from the
table, iow he can UPDATE rows he is not allowed to SELECT.

Is there a compelling use case for this? Where it really makes sense to
let users update/delete rows they cannot see via row security? We
support it in the table based permissions model, but it's possible to do
it with much saner semantics there. And with row security, it'll be
possible with security definer functions. I intend to add a "row
security exempt" flag for functions down the track, too.

Use case: https://en.wikipedia.org/wiki/Bell-La_Padula_model - being able to write up and read down access levels.

So for instance in healthcare, a data enterer may enter from hand written notes sensitive data (like subject has aids) in the electronic health record, without having general read access of the level of sensitivity of aids diagnosis. I think what is important in use cases like this, is that at data entry time, the actual data is still at the desk, so having data returned for inserts in the running transaction might not be problematic. As most EHR's today are additive in nature, future additions about the aids conditions would be inserts as well, no updates required. For updates my best guess would be that allowing the command to run with rls permissions different from the select is not required.


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to