On Tue, Jul 1, 2014 at 3:33 AM, Dean Rasheed <dean.a.rash...@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:


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

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

Reply via email to