On Fri, Dec 11, 2009 at 4:26 PM, Stephen Frost <sfr...@snowman.net> wrote: > Hrm, I thought I had given a specific example. Didn't do a good job of > it, apparently. Let me try to be a bit more clear: > > ALTER TABLE x OWNER TO y; > > If given the table OID, there's a ton of information we can then pull > about the table- the tablespace, the owner, the schema, the columns, the > privileges, etc, etc. > > What we can't possibly figure out from the OID is the value of y. Yet, > in the PG security model, the value of y matters! You have to know what > y is to check if y has 'create' rights on the schema. If it doesn't > (and the user executing the command isn't the superuser) then the > request (under the PG model) is denied. > > 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. 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. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
