Re: Row-security on updatable s.b. views - Mailing list pgsql-hackers

From Yeb Havinga
Subject Re: Row-security on updatable s.b. views
Date
Msg-id 53182EEB.2020702@gmail.com
Whole thread Raw
In response to Re: Row-security on updatable s.b. views  (Craig Ringer <craig@2ndquadrant.com>)
List pgsql-hackers
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




pgsql-hackers by date:

Previous
From: Ronan Dunklau
Date:
Subject: Re: Triggers on foreign tables
Next
From: Teodor Sigaev
Date:
Subject: Re: jsonb and nested hstore