Re: New Privilege model purposal

Karel Zak <zakkr@zf.jcu.cz>

From: Karel Zak <zakkr@zf.jcu.cz>
To: Jan Wieck <JanWieck@Yahoo.com>
Cc: Peter Eisentraut <peter_e@gmx.net>, PostgreSQL HACKERS <pgsql-hackers@postgresql.org>
Date: 2000-07-26T07:04:21Z
Lists: pgsql-hackers
On Tue, 25 Jul 2000, Jan Wieck wrote:

> Karel Zak wrote:
> >
> >  I not sure, but if I good remember nobody said somethig bad about
> > PetreE proposal for this, why you prepare new? IMHO Peter's proposal
> > was good.
> 
>     Seems  I  missed  that  discussion. Sometimes I start to drop
>     incoming eMails by subject. If then the discussion  moves  to
>     something  different  without changing the subject, you won't
>     see me on that.
> 
>     Anyway, I  haven't  found  a  complete  proposal  in  the  ML

I (mostly) have found nothing in PG's mail lists archive :-(
better is use:

http://www.deja.com/[ST_rn=fs]/group/mailing.database.pgsql-hackers

>     archive.   Consider  my proposal "derived work" from his one,
>     if it is similar and let's combine all  the  ideas  into  one
>     complete thing.

I mean will good if Peter re-posts his proposal. IMHO is not a problem
select feature for GRANT, a problem is implement it and implement it 
like SQL92.

> >  And small suggestion, we need the "GRANT ... WITH ADMIN OPTION" or
> > something like this.
> 
>     What should that do?

--- See the chapter "11.36  <grant statement>" in the SQL92 (and others
    parts of this standard). SQL92:

         <grant statement> ::=
              GRANT <privileges> ON <object name>
                TO <grantee> [ { <comma> <grantee> }... ]
                  [ WITH GRANT OPTION ]


--- "WITH ADMIN OPTION" is Oracle matter, and Oracle's manual say:

	".. allows the grantee to grant the object privileges to the
	 other user and role..."
 
 other words you can create "sub-admin" for the object, and this user 
can GRANT privilege to the other standard users.
 
 It is pretty well implement-able if all privilege will in one system 
table (pg_privilege). I mean that is not good "dirty" other system 
tables.

 The other point --- we must keep open a door to others SQL administration
features like ROLE, PROFILE. IMHO final proposal should be contain some idea 
for group/shadow rewriting and some idea about ROLE.

 Ops.. I forget, we *must* in new ACL have columns privilege. It is realy
needful in large multi-user applications. A crash point will seed :-)

 						Karel