Re: fcntl(SETLK) [was Re: 2nd update on TOAST]

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 they run. This should normally be
`/usr/local/com', but write it as `$(prefix)/com'. (If you are
using Autoconf, write it as `(at)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, but it 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 writable by 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(at)gmx(dot)net 75262 Uppsala
http://yi.org/peter-e/ Sweden