Re: Per database users/admins, - Mailing list pgsql-hackers

From Richard Huxton
Subject Re: Per database users/admins,
Date
Msg-id 49175.192.168.1.32.1080337408.squirrel@mainbox.archonet.com
Whole thread Raw
In response to Re: Per database users/admins, handy for database virtual hosting...  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> Richard Huxton <dev@archonet.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.


pgsql-hackers by date:

Previous
From: markw@osdl.org
Date:
Subject: PostgreSQL block size vs. LVM2 stripe width
Next
From: Tom Lane
Date:
Subject: GIST code doesn't build on strict 64-bit machines