Re: Open 7.3 items - Mailing list pgsql-hackers

Lamar Owen wrote:
> On Wednesday 14 August 2002 03:29 pm, Vince Vielhaber wrote:
> > Hate to complicate things more, but back to a global username, say
> > you have user "lowen" that should have access to all databases.  What
> > happens if there's already a lowen@somedb that's an unprivileged user.
> > Assuming lowen is a db superuser, what happens in somedb?  If there's
> > a global user "lowen" and you try to create a lowen@somedb later, will
> > it be allowed?
> 
> If the user 'lowen' is then expanded to 'lowen@template1' it would be stored 
> that way -- and lowen@template1 is different from lowen@pari, for instance.  
> The lowen@template1 user could be a superuser and lowen@pari might not -- but 
> they become distinct users.  Although I do understand the difficulty if the 
> FQDU isn't stored in full in the appropriate places.  So I guess the solution 
> is that wherever a user name is to be stored, the fully qualified form must 
> be used and checked against, with @template1 being a 'this user is 
> everywhere' shorthand.

Yes, Vince is on to something with his quote above.

If we have users with and without @, we get into the situation where
users without @ may become users with @ when their usernames collide
with existing user/db combinations already created.  The point is that
those two namespaces do collide and will cause confusion.

Then you start to get into the situation where you always add @ and make
@template1 a special case.  However, remember that this flag can be
turned on and off after initdb, so you need to be able to get in to set
things up without great complexity _and_ the @template1 would not be
passed in from the client, if for no other reason that the username is
only 32 characters. It is the backend doing the flagging, and therefore
the user can't say 'I am dave@templatge1' vs 'I am dave@connectdb'.

This is how I got to the installuser hack in the first place.  In fact,
even the install user, typically 'postgres' has a problem because if you
create 'postgres@db1', 'postgres' will have trouble connecing to db1 as
themselves. I think we can live with one user who is special/global, but
not more than one because of the confusion it would create.

I can change the way this works, but we need a solution without holes.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073