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;
> regression=# create user u2;
> regression=# \c - u1
> You are now connected to database "regression" as user "u1".
> regression=> create table t1(f1 int);
> regression=> create view v1 as select * from t1;
> regression=> grant select on v1 to u2;
> -- 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;
> 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?

  Bruce Momjian   [EMAIL PROTECTED]

  + If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Reply via email to