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 [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly