* 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: 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. > 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. Thanks, Stephen
signature.asc
Description: Digital signature