On Fri, 17 Mar 2000, Kardos, Dr. Andreas wrote:
> Since I havn't got any reply from the hackers list, I'm resending this here
> to not lose it.
Sorry, I'm a little busy these days. Lots of mail to catch up with ...
> > On
> > CREATE USER username CREATEUSER
> > both pg_user.usesuper and pg_user.usecatupd are set to true.
> >
> > An
> > ALTER USER username CREATEUSER
> > sets pg_user.usesuper to true only, but not pg_user.usecatupd. The only
> way
> > to set pg_user.usecatupd to true is on creation.
I have spend a lot of time pondering exactly this issue when I wrote it. I
guess you can flip it either way. On the one hand "CREATEUSER" has
traditionally been synonymous with "superuser" (which is a problem, I
believe), and catupd was created so that superusers are "protected from
themselves" so they should not be intermixed.
The reason that create user sets usecatupd to true is if you happen to
have no user left with usecatupd you can't really go in an alter
pg_shadow, ey? Then you can create a new superuser (assume you have *some*
superuser left) and rethink all your privileges again.
I don't recall exactly what it did earlier but this is still bogus as it
is. Answer no.1 would be to never grant usecatupd automatically but
instead exempt pg_shadow from the privileges it describes (that sentence
right there describes why this is all a problem). Answer no.2 would be to
add usecatupd to the create/alter user set but I'd like to wait to
redesign the create/alter user syntax for that. No.3 would be to have
alter user set usecatupd = usesuper in any case. (What if you revoke
superuser privileges? Should you revoke catupd as well?)
I'm open for ideas. This is all very confusing.
(Note: Lately I've been thinking of variant no.4: only have one superuser
period, like in Unix. You'd never use that superuser for normal use. If
you want to give your users superuser access, give them the password (or
whatever you have set up). The current scheme of potentially many
superusers perfectly lends itself to the "I do everything as root" abuse
and is also very vulnerable because one superuser can easily revoke
superuser privilege from all the others.)
--
Peter Eisentraut Sernanders väg 10:115
[EMAIL PROTECTED] 75262 Uppsala
http://yi.org/peter-e/ Sweden
