Re: [HACKERS] Re: [SQL] createdb -D xxxx not working - Mailing list pgsql-hackers

On 2000-01-11, Thomas Lockhart mentioned:

> > >> Surely you want $PGDATA2 in the latter two lines?
> > > You might recall me mentioning that the whole alternative location
> > > business doesn't work in the first place.
> 
> I'm not recalling the details here; what is the problem? It works for
> me (but then I wrote it ;)
> 

Darn, now I already rewrote the thing to where I considered it working. We
had several on-and-off discussions (mostly Tom and I) about it during the
last two months at least, including users complaining.

The sort of scheme I came up with scraps the environment variable stuff
(since it's not quite safe either and has several bugs in the code that
create a bunch of problems along the way) and lets the following
happen (example paths):

CREATE DATABASE foo;    --> /usr/local/pgsql/data/base/foo/pg_class
CREATE DATABASE foo WITH LOCATION 'bar';        --> /usr/local/pgsql/data/base/bar/pg_class
CREATE DATABASE foo WITH LOCATION '/some/where';        --> /some/where/pg_class
CREATE DATABASE foo WITH LOCATION 'foo/bar';        is disabled. I suppose I could stick the
environment variable deal back in so that users don't have to remember any
complicated paths, but this is the dbadmin's job anyway, so he should be
able to remember it.

Anyway, in order for a path to be allowed it has to be listed in
PG_ALTLOC, which is a colon-delimited, marginally wildcard enabled list of
allowed locations. In some future life this could be included in a
configuration file.


> initlocation is used to create the directory structure *with correct
> permissions* for an alternate location. It takes an environment

I think one of the problems was actually that the path initlocation
assumed and the one createdb worked with were different.

> variable because usually the backend should have that same environment
> variable defined to ensure consistancy and as a security measure. The
> environment variable can be expanded or not; initlocation does the
> right thing in either case.

It's false security though, since for complete security the dbadmin would
have to delete all other environment variables altogether.

> > I'd vote for taking
> > out the auto-expansion, so that the correct invocation becomes
> >         initlocation $PGDATA2
> > which is what an average user would expect.
> 
> But the average user does not necessarily have access to the PGDATA2
> environment variable! This is usually a sysadmin function.

The average user doesn't even have access to the machine the database is
running on, so he can't do any initlocation either way. Then again the
average user doesn't create databases either. But there is no real point
for initlocation since a mere mkdir() call in createdb() will do the job.


Now I just got done with that coding 10 minutes ago but now that someone
actually spoke up in defence of this mechanism I'm going to wait and see
what you think about the revised (or any) scheme.

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