Robert Haas wrote:
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.
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 <kai...@kaigai.gr.jp>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
