Re: Altering view ownership doesn't work ...

Reminding folks this bug is still open.

---------------------------------------------------------------------------

Tom Lane wrote:
> ... because nowhere does it update the "checkAsUser" fields in the
> view's query to be the OID of the new owner.  This means that
> permission checks about whether the view can access its underlying
> tables will still be done as the old owner.  An example:
> 
> regression=# create user u1;
> CREATE ROLE
> regression=# create user u2;
> CREATE ROLE
> regression=# \c - u1
> You are now connected to database "regression" as user "u1".
> regression=> create table t1(f1 int);
> CREATE TABLE
> regression=> create view v1 as select * from t1;
> CREATE VIEW
> regression=> grant select on v1 to u2;
> GRANT
> 
> -- at this point u2 can select from v1 but not directly from t1
> 
> regression=> \c - postgres
> You are now connected to database "regression" as user "postgres".
> regression=# alter table v1 owner to u2;
> ALTER TABLE
> regression=# \c - u2
> You are now connected to database "regression" as user "u2".
> regression=> select * from v1;
>  f1 
> ----
> (0 rows)
> 
> -- this is WRONG, u2 should not have any ability to select from t1
> 
> The same problem applies to all rules, really, not only a view's
> ON SELECT rule.
> 
> This is particularly bad because pg_dump is relying heavily on
> ALTER OWNER these days.  After a dump/restore, it is likely that
> every view's "original owner" will be a superuser, and thus that
> all permission checking is effectively disabled for accesses
> from views.  It wouldn't be too much of a stretch to call that
> a security loophole.
> 
> I can think of two basic ways to fix this:
> 
> 1. Add a bunch of code to ALTER OWNER to update every rule attached to
> the target table.
> 
> 2. Run setRuleCheckAsUser during rule load rather than rule store.
> 
> #2 is a lot simpler, and would fix the problem for existing broken rules
> whereas #1 would not, so I'm kind of inclined to go with that.  I doubt
> there'd be any meaningful performance hit --- parsing the stored form
> of a rule is relatively expensive anyway, so we cache the results.
> 
> Comments?
> 
>             regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
> 
>                http://www.postgresql.org/docs/faq

--  Bruce Momjian   bruce@momjian.us EnterpriseDB    http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +