Hmm, I thunk I was working on that. I put out a proposal on May 22, and we
came to a pretty good understanding about the details and I was working on
a new specification.
Your approach seems to be missing column-level privileges and grant
options, and is in general not very close to SQL.
> With
> some new features (referential integrity for example),
> this system isn't flexible enough any more and need to be
> expanded or replaced soon.
I think the RI snafu at least is not the fault of the privilege system at
all. I could blame the implementation, but short of that it's actually the
fault of the function manager in that it cannot execute functions with the
permissions of the creator, as mandated by SQL. That's the thing that
needs to be fixed (but it reaches throughout the code of course).
> ALTER SESSION Permission to change session specific
> attributes like character set
> localization.
GRANT USAGE ON CHARACTER SET
> CREATE TABLE Permission to create new table in a
> database.
This needs to be tied in with schemas.
> Pg_shadow is extended with an array, holding all the
> groups the user belongs to. So after looking up the
> user, all group relationships are known.
We ought to think in terms of SQL roles. Those are nestable, so arrays
need to be out of the picture.
> The system will manage a stack, remembering nested
> states of the effective user id. Calls through the
> function manager can switch for- and backward to
> another one, so prosetuid functions will inherit the
> effective permissions of the function (trigger)
> owner. The stack is reinitialized at transaction
> aborts.
This is definitely necessary, but it needs to be more general. There is a
command SET SESSION AUTHORIZATION, which is essentially `su', that could
make use of this also.
--
Peter Eisentraut Sernanders väg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden