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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company