On Mon, Jul 27, 2015 at 4:58 PM, Stephen Frost <sfrost@snowman.net> wrote:
>> I would expect that if the current user has permission to bypass RLS,
>> and they have set row_security to OFF, then it should be off for all
>> tables that they have access to, regardless of how they access those
>> tables (directly or through a view). If it really is intentional that
>> RLS remains active when querying through a view not owned by the
>> table's owner, then the other calls to check_enable_rls() should
>> probably be left as they were, since the table might have been updated
>> through such a view and that code can't really tell at that point.
>
> Joe and I were discussing this earlier and it was certainly intentional
> that RLS still be enabled if you're querying through a view as the RLS
> rights of the view owner are used, not your own. Note that we don't
> allow a user to assume the BYPASSRLS right of the view owner though,
> also intentionally.
That seems inconsistent. If querying through a view doesn't adopt the
BYPASSRLS right (or lack thereof) of the view owner, and I agree that
it shouldn't, then it also shouldn't disregard the fact that the
person issuing the query has that right.
In other words, we've made a decision, when going through views, to
test ACLs based on who owns the view. We do that in all cases, not
only sometimes. Now, when querying a view, whose BYPASSRLS privilege
do we consult? It should either be the person issuing the query in
all cases, or the view owner in all cases, not some hybrid of the two.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company