Re: Open 7.3 items

OK, I have attached a patch for testing. Sample output is:

$ sql -U guest test
psql: FATAL: user "test.guest" does not exist
$ createuser test.guest
Shall the new user be allowed to create databases? (y/n) n
Shall the new user be allowed to create more new users? (y/n) n
CREATE USER
#$ sql -U guest test
Welcome to psql, the PostgreSQL interactive terminal.

Type: \copyright for distribution terms
\h for help with SQL commands
\? for help on internal slash commands
\g or terminate with semicolon to execute query
\q to quit

test=>

The patch is quite small. All it does is prepend the database name to
the user name supplied with the connection request when
db_user_namespace is true.

This is not ready for application. I can find no way from the
postmaster to determine if the user is the super-user and hence bypass
the database prepending. I was going to do that _only_ for the username
who created the installation for initdb. Maybe I have to dump that name
out to a file and read it in from the postmaster. Other ideas?

It also needs documentation.

I am unsure about auto-prepending the dbname for CREATE USER and other
cases. That could get confusing, especially because createuser accesses
template1, and we would have to handle all other username mentions, like
in GRANT. We may be better just leaving it along and telling admins
they have to quality the username in those cases.

---------------------------------------------------------------------------

Marc G. Fournier wrote:
> On Wed, 31 Jul 2002, Bruce Momjian wrote:
>
> > Marc G. Fournier wrote:
> > > On Wed, 31 Jul 2002, Bruce Momjian wrote:
> > >
> > > > Marc G. Fournier wrote:
> > > > > > Access to nothing. I could actually try to quality by dbname.username,
> > > > > > then fall back to just username, but that seems insecure.
> > > > >
> > > > > No, that's cool ... just questions I thought of ...
> > > >
> > > > OK.
> > > >
> > > > > Okay ... hmmm ... just making sure that I understand ... I setup a server,
> > > > > when does this dbname.* come into play? Only if I enable password/md5 in
> > > > > pg_hba.conf for a specific database? all others would still use a plain
> > > > > 'username' still works? or are you getting rid of the 'global usernames'
> > > > > altogether (which is cool too, just want to clarify) ...
> > > >
> > > > There will be a GUC param db_user_namespace which will turn it on/off
> > > > for all access to the cluster _except_ for the super-user.
> > >
> > > Okay ... cluster == database server, or a subset of databases within the
> > > server? I know what I think of as a cluster, and somehow I suspect this
> > > has to do with the new schema stuff, which means I *really* have to find
> > > time to do some catch-up reading ;) need more hours in day, days in week
> >
> > Cluster is db server in this case.
>
> 'K, cool, thanks :)
>
> Okay, final request .. how hard would it be to pre-pend the current
> database name if GUC value is on? ie. if I'm in db1 and run CREATE USER,
> it will add db1. to the username if I hadn't already? Sounds to me it
> would be simple to do, and it would "fix" the point I made about being
> able to have a db "owner" account with create user privileges (ie. if I'm
> in db1 and run CREATE USER db2.bruce, it should reject that unless I've
> got create database prileges *and* create user) ...
>
> Other then that, most elegant solution, IMHO :)
>
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026