Re: A little RLS oversight?

Robert,

* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> On Mon, Jul 27, 2015 at 4:58 PM, Stephen Frost <sfrost(at)snowman(dot)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.

That's not how other role attributes currently work though, specifically
thinking of superuser. Even when running a query as a superuser you can
get a permission denied if you're querying a view where the view owner
hasn't got access to the relation under the view.

=# create role r1;
CREATE ROLE
=*# create role r2;
CREATE ROLE
=*# create table t1 (c1 int);
CREATE TABLE
=*# alter table t1 owner to r1;
ALTER TABLE
=*# create view v1 as select * from t1;
CREATE VIEW
=*# alter view v1 owner to r2;
ALTER VIEW
=*# select * from v1;
ERROR: permission denied for relation t1

> 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.

For superuser (the only similar precedent that we have, I believe), we
go based on the view owner, but that isn't quite the same as BYPASSRLS.

The reason this doesn't hold is that you have to use a combination of
BYPASSRLS and row_security=off to actually bypass RLS, unlike the
superuser role attribute which is just always "on" if you've got it. If
having BYPASSRLS simply always meant "don't do any RLS" then we could
use the superuser precedent to use what the view owner has, but at least
for my part, I'm a lot happier with BYPASSRLS and row_security than with
superuser and would rather we continue in that direction, where the user
has the choice of if they want their role attribute to be in effect or
not.

Thanks,

Stephen