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.
regards,
Yeb
