Skip site navigation (1) Skip section navigation (2)

AW: New Privilege model purposal

From: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>
To: "'Jan Wieck'" <JanWieck(at)Yahoo(dot)com>, PostgreSQL HACKERS <pgsql-hackers(at)postgresql(dot)org>
Subject: AW: New Privilege model purposal
Date: 2000-07-26 08:20:56
Message-ID: 11C1E6749A55D411A9670001FA68796336802D@sdexcsrv1.f000.d0188.sd.spardat.at (view raw or flat)
Thread:
Lists: pgsql-hackers
>       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

pgsql-hackers by date

Next:From: Zeugswetter Andreas SBDate: 2000-07-26 08:44:22
Subject: AW: AW: Vacuum only with 20% old tuples
Previous:From: Karel ZakDate: 2000-07-26 07:04:21
Subject: Re: New Privilege model purposal

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group