Peter Eisentraut <e99re41@DoCS.UU.SE> writes:
> There is a very good reason for running the installation process as any
> user you choose,
Not "as any user you choose", but as *root* --- the
can't-make-top-directory problem can only be solved by root, and on many
systems only root can chown files to another account anyway.
The difficulty with encouraging people to su to root for install is that
it's so easy to make the files root-owned and thereby create a security
problem. Perhaps the right compromise is to add a --owner switch to
"make install", and to have it refuse to install if the (given or
defaulted) ownership is "root" ?
Actually, something I'm not real clear on right at the moment is whether
it is safe to make the dirs/files created by install be root-owned or not.
The ownership of the data directory and everything below it must be
postgres (s/postgres/your unprivileged user of choice/g) because the
running postgres process must be able to write in those dirs. But
offhand I can't think of any reason that any postgres-owned processes
need to be able to write in the bin, lib, or include hierarchies. Can
anyone else think of one?
Maybe the proper approach is "OK, do make install as root if you feel
like it; we don't care whether that stuff is root-owned". Only initdb
would need to have a --owner switch and take care that the files/dirs
it makes are not left root-owned. Then the install sequence could
look like
./configure
make
su root
make install
initdb --owner=postgres --pgdata=whatever
exit from su
start postmaster
BTW, do we have a check in the postmaster to refuse to start if its euid
is root? Shouldn't we?
regards, tom lane
PS:
> No, seriously: *which* system doesn't have dirname? Does it have basename?
Horton says that dirname was originally SysV and was standardized in
POSIX.1. I'd expect it to be present on most systems these days, but
probably there are still some old BSD machines that ain't got it. He
rates basename as fully portable though.
Basically my take on this stuff is to conform to existing GNU portability
practices except where we have very good reason to do otherwise. It's
not that hard to use the GNU workaround for dirname, so why not do it...
