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

Agreed, RULE permissions seem to be of limited usefulness.

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

Tom Lane wrote:
> Martijn van Oosterhout <kleptog(at)svana(dot)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(at)postgresql(dot)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. +