Robert Haas wrote:
> 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.
Theoretically, (x,y,u) -> (x,y,u,v) -> (x,y,u,v,w) may happen.
However, if the new suggested security model is too far from the known
security model, we should consider whether it performs correctly at first
before commit it.
As long as we describe a security model corresponding to database objects,
it is hard to consider a possibility of infinite increasing in the future.
Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>
