> SUPERUSER A special System Privilege,
This priv is usually called DBA
> CREATE SESSION Permission to login. Checked after
usually called CONNECT
The several CREATE privs are usually all granted with one grant
RESOURCE statement
> 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.
Imho it would be nice to have hierarchical groups.
That is a group can consist of users and/or other groups.
> Two new system catalogs, pg_userprivilege and
> pg_groupprivilege are created to hold the actual
> privileges. They are members of the system cache for
> fast lookup.
I would probably stick to one table to hold the privs (e.g. pg_auth)
then you can get all privs for one object with one select.
There has been some previous discussion about the layout for such a
table.
> 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.
Since we have such powerful extensibility I would also keep the
OS user in mind. Imho the fmgr should also be capable of switching
to another effective uid on the os level to call certain functions
that do something on the os level. (just keep in mind not implement now)
Andreas