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

Agreed, RULE permissions seem to be of limited usefulness.

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

Tom Lane wrote:
> 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
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
>        subscribe-nomail command to majordomo@postgresql.org so that your
>        message can get through to the mailing list cleanly
> 

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