Re: Altering view ownership doesn't work ... - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Altering view ownership doesn't work ...
Date
Msg-id 27436.1146417435@sss.pgh.pa.us
Whole thread Raw
In response to Re: Altering view ownership doesn't work ...  (Martijn van Oosterhout <kleptog@svana.org>)
Responses Re: Altering view ownership doesn't work ...
List pgsql-hackers
Martijn van Oosterhout <kleptog@svana.org> writes:
> On Sun, Apr 30, 2006 at 12:34:42PM -0400, Tom Lane wrote:
>> 2. Run setRuleCheckAsUser during rule load rather than rule store.

> FWIW, I think #2 is better also.

Actually, I'm sitting here realizing the problem is more complicated
than I thought :-(.  The spanner in the works is the existence of the
RULE privilege --- a table owner can grant someone else the right to add
rules to his table.  As things currently work, when the someone else
does so, it's *his* OID not the table owner's that gets put into the
rule's checkAsUser fields.  Thus for example the someone else could add
a logging rule that makes entries into a table that the actual table
owner has no permissions for.

Whether or not you consider that sort of thing useful, it would
certainly be bad to use the table owner's OID for such permission
checks, because then granting RULE privilege on any table would be
tantamount to handing over every permission the table owner has ---
the grantee would be able to install arbitrary SQL to be executed as
the table owner.  So really the RULE privilege only makes sense if a
rule is considered to be a separate object with separate ownership.

So it seems we either have to abandon the separate RULE privilege
(and just say that only table owners can install rules, and the
rules are always executed as though by the current owner), or we
have to promote rules to be fully separately owned objects.  The
latter will be a horrid mess, in particular it will break existing
dump files that just ALTER the table's owner and don't go through
altering ownership of individual rules.  (No, we can't have ALTER
TABLE OWNER automatically recurse to the individual rules, that'd just
create the same Trojan-horse situation where a malicious rule now has
the privileges it didn't have to start with.)

I'm inclined to think that the best choice is to drop the separate
RULE privilege.  It's an interesting feature but I gauge its actual
usefulness by the fact that I didn't even realize it worked like that.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Martijn van Oosterhout
Date:
Subject: Re: Altering view ownership doesn't work ...
Next
From: mark@mark.mielke.cc
Date:
Subject: Re: Is a SERIAL column a "black box", or not?