On Fri, Dec 11, 2009 at 4:26 PM, Stephen Frost <sfrost@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