Tom Lane writes:
> However, I think it would be a really bad idea to keep the lock files
> in /tmp --- that's way too open to accidental removals, not to mention
> deliberate denial-of-service attacks. They need to be in a more secure
> directory; but where? See the past discussions summarized in the
> TODO.detail file.
Quoth the file system standard:
`sharedstatedir' The directory for installing architecture-independent data files which the programs modify while
theyrun. This should normally be `/usr/local/com', but write it as `$(prefix)/com'. (If you are using Autoconf,
writeit as `@sharedstatedir@'.)
The problem with this approach is making that directory writeable by the
server account. Solutions:
1) Making the postmaster executable as root but later drop root privileges. (This looks to be the cleanest solution,
butit is probably a security problem waiting to happen.)
2) Making initdb executable as root but with some --user switch. Have it create a subdirectory of $sharedstatedir
writableby the server account, possibly with sticky bit and whatnot. Use `su' to invoke `postgres'.
This approach might be convenient also in terms of creating the data directory.
3) Making "initialize lock file area" a separate initialization step, possibly encapsulated into a shell script.
Btw., what would happen if we did start a second postmaster at the same
TCP port? Or more interestingly, what happens if some completely different
program already runs at that port? How do we protect against that? This
has something to do with SO_REUSEADDR, but I don't understand those things
too well.
--
Peter Eisentraut Sernanders väg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
