| From: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> |
|---|---|
| To: | Dennis Bjorklund <db(at)zigo(dot)dhs(dot)org> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, sergiomb(at)netcabo(dot)pt |
| Subject: | Re: Big problem |
| Date: | 2004-05-24 15:03:02 |
| Message-ID: | 40B20EA6.8090207@familyhealth.com.au |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> Isn't it just enough to prevent the user with userid 1 from losing the
> superuser status. If one want to allow it one could prevent it just when
> doing the ALTER USER stuff and allow it when editing pg_shadow directly.
> Or maybe have some guc variable that write locks the user with id 1.
That gets my vote - can't take superuser off id 1...
> Given that it was so "simple" to restore I'm not sure if it's worth it or
> not, but restricting just user 1 does not give any of the problems you
> wrote about.
Well, sergio sure wasn't very happy...
And if I ever get around to my patch that separates out superuser and
catalog modification privileges, superusers will no longer necessarily
be able to 'delete from pg_proc';
Chris
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Manfred Koizar | 2004-05-24 16:00:36 | Re: zero-column table behavior |
| Previous Message | Dennis Bjorklund | 2004-05-24 14:55:51 | Re: Big problem |