Re: Per database users/admins,

From: "Richard Huxton" <dev(at)archonet(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Richard Huxton" <dev(at)archonet(dot)com>, "Sean Chittenden " <sean(at)chittenden(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Per database users/admins,
Date: 2004-03-26 21:43:28
Message-ID: 49175.192.168.1.32.1080337408.squirrel@mainbox.archonet.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Richard Huxton <dev(at)archonet(dot)com> writes:
>> Maybe it's me being slow, but are we not being over-complicated here?
>> What's
>> wrong with saying "database D1 looks up users in local table, D2 in the
>> global table". If you are connected to D1, then no-one can see the
>> global
>> userlist.
>
> Hmm. That would amount to saying that there are no global superusers
> for D1, which might be a bit of a problem --- if local DBA paints
> himself into a corner, you can't get him out. Backing up a cluster that
> has not got global superusers would be a PITA too.

So you write a script to add a local superuser when you create the
database. Or, we could do it in the createdb/CREATE DATABASE code - just
clone the "postgres" user. Last resort, I'm sure the files themselves
could be hacked if you had to. If people are running a shared environment,
it's fair to assume they know a little of what they're doing.

> Still, I think you are right that we gotta think outside the box if
> we're going to find a way to do this.

More a case of thinking under the box here.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message markw 2004-03-26 22:00:01 PostgreSQL block size vs. LVM2 stripe width
Previous Message Tom Lane 2004-03-26 21:30:39 GIST code doesn't build on strict 64-bit machines