| From: | Dennis Bjorklund <db(at)zigo(dot)dhs(dot)org> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, <sergiomb(at)netcabo(dot)pt> |
| Subject: | Re: Big problem |
| Date: | 2004-05-24 14:55:51 |
| Message-ID: | Pine.LNX.4.44.0405241651100.24368-100000@zigo.dhs.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, 24 May 2004, Tom Lane wrote:
> I think the cure would probably be worse than the disease. To make any
> serious attempt at preventing remove-the-last-superuser, we'd have to
> make operations on pg_shadow grab exclusive lock. For instance, you
> couldn't allow two backends to DROP USER in parallel; they might be
> dropping the last two superusers, but neither one would think it was
> creating a problem. And while we could theoretically make
> CREATE/ALTER/DROP USER take such locks, I dunno how you make a straight
> "DELETE FROM pg_shadow" do so.
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.
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.
--
/Dennis Björklund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Christopher Kings-Lynne | 2004-05-24 15:03:02 | Re: Big problem |
| Previous Message | Tom Lane | 2004-05-24 14:49:23 | Re: Big problem |