On 1 July 2014 17:42, Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, Jul 1, 2014 at 3:33 AM, Dean Rasheed <dean.a.rasheed@gmail.com> wrote:
>> An annoying complication, however, is how this interacts with column
>> privileges. Right now "GRANT SELECT(col1) ON t1 TO role1" gives role1
>> access to every row in col1, and I think that has to remain the case,
>> since GRANTs only ever give you more access. But that leads to a
>> situation where the RLS quals applied would depend on the columns
>> selected.
>
> Wow, that seems pretty horrible to me. That means that if I do:
>
> SELECT a FROM tab;
>
> and then:
>
> SELECT a, b FROM tab;
>
> ...the second one might return fewer rows than the first one.
>
> I think there's a good argument that RLS is unlike other grantable
> privileges, and that it really ought to be defined as something which
> is imposed rather than a kind of access grant. If RLS is merely a
> modifier to an access grant, then every access grant has to make sure
> to include that modifier, or you have a security hole. But if it's a
> separate constrain on access, then you just do it once, and exempt
> people from it only as needed. That seems less error-prone to me --
> it's sort of a default-deny policy, which is generally viewed as good
> for security -- and it avoids weird cases like the above, which I
> think could easily break application logic.
>
That seems like a pretty strong argument.
If RLS quals are instead regarded as constraints on access, and
multiple policies apply, then it seems that the quals should now be
combined with AND rather than OR, right?
Regards,
Dean
