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