On Fri, Dec 11, 2009 at 5:36 PM, Stephen Frost <sfr...@snowman.net> wrote: > * Robert Haas (robertmh...@gmail.com) wrote: >> On Fri, Dec 11, 2009 at 4:26 PM, Stephen Frost <sfr...@snowman.net> wrote: >> > Does that help clarify my example case? >> >> That case doesn't seem terribly problematic to me. It seems clear >> that we'll want to pass some information about both x and y. What is >> less clear is exactly what the argument types will be, and the right >> answer probably depends somewhat on the structure of the existing >> code, which I have not looked at. > > Allow me to assist- y is never in a structure once you're out of the > parser:
Well this is why you're writing the patch and not me. :-) > ATExecChangeOwner(Oid relationOid, Oid newOwnerId, bool recursing) > > I expect you'll find this is more the rule than the exception to alot of > the existing PG security model, because much of it's responsibility is > in what I'll call the DDL (under commands/) aspects. The DML pieces > (under the executor) are a bit better about this, specifically you could > pass in a RangeTblEntry, exactly how ExecCheckRTEPerms handles it. > > Actually, in a fit of barely-contained mirth, it strikes me that PG > really has already done what you're suggesting for the 'hard' part- and > the RangeTblEntry plus ExecCheckRTEPerms is exactly it. It's all the > *other* checks we do for the PG security model, under commands/, that > are the problem here. The parts of the code that, to be honest, I think > all us database geeks have historically cared alot less about. Hmm, interesting. >> What I'm more concerned about is if >> the access control decision in this case were based on u for PG DAC, v >> for SE-PostgreSQL, and w for Robert Haas's Personal Defensive System. >> If that's the case, and our function signature looks like (x,y,u,v,w), >> the we should worry. > > Right, I understand that. What I offer in reply is that we focus our > attention on using the OID+SubOID approach, as I'm suggesting, to the > fullest extent possible through that mechanism, and appreciate that the > other arguments passed to the function are derived specifically from the > parser and therefore unlikely to be changed until and unless we change > the base syntax of the command and calling function, at which time we > may have to add arguments to the function signature. This would > continue at least until we get to the point where we decide that the > caller needs to be changed because it's got a huge function sig, and > move it to something like the structure of the executor and the > equivilant of ExecCheckRTEPerms() would get updated along with it, at > that time. What exactly do you mean by a SubOID? I'm not really following that part. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
