In my venturing into createdb/dropdb I came to that little artifact that
allows you to create databases at alternate locations using environment
variables as part of the path (CREATE DATABASE elsewhere WITH LOCATION =
'PGDATA2/foo').
The problem with this is that it doesn't work. It never could have, and
God help you if you try to use it anyway. And it's not only one isolated
problem.
First off, the paths generated by the expansion and the ones generated by
initlocation are different, so the directory will never be found unless
you tweak it by hand. This can be fixed.
Worse, however, is that the expanded path is stored in pg_database (at
least in theory, since you never get there) and once you try to reference
(e.g., remove) the database, the same expansion routine will see the now
absolute path and refuses to allow it.
What really gets me, though, is how this sort of scheme is supposed to
create security in the first place. Perhaps I can create a path based on
the environment variable HOME, or maybe SHELL? Or how about this: you take
an empty environment variable and specify VAR/usr/local/pgsql/lib as your
path. Fun ensues! You can never completely control this stuff. ISTM, this
just makes things worse and more complicated.
How could we still keep this feature but select another method of
specifying the list of allowed paths? The Unix file permissions should
help, but that doesn't necessarily prevent anyone from frying your
existing databases, if you exercise a little imagination when specifying
the paths. How about a) something in some options file (lot of work), or
b) some environment variable of the form PGSQL_ALTLOC=path:path:path?
This is of course barring the potential fact that parts of the code which
I don't completely understand or which I haven't read yet prevent this
whole concept from working in other ways.
--
Peter Eisentraut Sernanders väg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden