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: 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
