Re: [HACKERS] More initdb follies - Mailing list pgsql-hackers

On 1999-12-08, Tom Lane mentioned:

> Makes sense to me --- I was saying more or less the same thing, I think,
> when I said that initdb should pay attention to the effective UID it's
> run under *and nothing else* to determine the postgres user name/ID.
> In particular, if you want to be able to run it via "su", it mustn't
> assume that environment variables like LOGNAME or USER are set correctly
> for the postgres user.  If it needs the user name it should look it up
> from the EUID.

(The odd thing is, that our installation instructions suggest to su as
postgres and do the install that way, yet this seems to work anyway. On my
system (GNU sh-utils), USER is only set if you 'su -', but it seems
relying on the user doing this right is way too much to ask.)

Hmm, portability issues. Can you be sure EUID is implemented everywhere?
(I guess so.) How do you determine the user name from a UID? That would be
the inverse of what pg_id does now.

An idea I just had would be to use
* First resort: `id -n -u`
* Second resort: `whoami`
* Third resort: --username option

The first two don't distinguish between su and su -, at least here. Not
sure if #3 is necessary though. One of those you should have.

On the other hand, one more thing to think about is that the only place
the superuser's UID and name are actually used, is to initialize the
catalogs. All the files will happily be created under which ever user you
run this as (as they should). Using the above three step approach, you can
choose to name your _database_ superuser whatever you want, independent of
the Unix filesystem concerns. Of course this is nothing to encourage, but
it's possible. I could install the system in my home directory in some
computing lab under my own user name, yet still name the superuser
postgres to have a standard environment within the database. I guess the
--username option does kind of work, just not as expected.

(The next thing would be the ability to choose the database superuser's
usesysid as well, which might not be so far-fetched either, because if
1) you already have 40000 users on your system when you install PostgreSQL
2) you assign the Unix user postgres the uid 400001
3) you add your 40000 users to the database
you end up with usesysid's 40000-80000 (+/- 1). Not the end of the world
but kind of dumb. The you could simply assign 0 (or 1 if zero is not
allowed) to the superuser at initdb time.)

There seem to be a lot of misconceptions (possibly caused by restrictions
in the past) about all the user names and ids of the installation files,
the data directory, the server process, the database users, the database
super user, etc. In fact, most of these can be chosen freely, the only
requirement is that the server process can access the data directory.

-- 
Peter Eisentraut                  Sernanders väg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden