Re: [HACKERS] flock patch breaks things here - Mailing list pgsql-hackers

>
> > The Hermit Hacker <scrappy@hub.org> writes:
> > > either way, moving the pid file (or
> > > socket, for that matter) from /tmp should be listed as a security related
> > > requirement for v6.4 :)
> >
> > Huh?  There is no pid file being generated in /tmp (or anywhere else)
> > at the moment.  If we do add one, it should not go into /tmp for the
> > reasons I gave before.
> >
> > Where the Unix-domain socket file lives is an entirely separate issue.
> >
> > If we move the socket out of /tmp then we have just kicked away all the
> > work we did to preserve backwards compatibility of the FE/BE protocol
> > with existing clients.  Being able to talk to a 1.0 client isn't much
> > good if you aren't listening where he's going to try to contact you.
> > So I think I have to vote in favor of leaving the socket where it is.
>
> I have been thinking about this.  First, we can easily use fopen(r+) to
> check to see if the file exists, and if it does read the pid and do a
> kill -0 to see if it is running.  If no one else does it, I will take it
> on.
>
> Second, where to put the pid file.  There is reason to put in /tmp,
> because it will get cleared in a reboot, and because it is locking the
> port number 5432.  There is also reason to put it in /data because you
> can't have more than one postmaster running on a single data directory.
>
> So, we really want to lock both places.  If this is going to make it
> easier for people to run more than one postmaster, because it will
> prevent/warn administrators when they try and put two postmasters in the
> same data dir or port, I say create the pid lock files both places, and
> give the admin a clear description of what he is doing wrong in each
> case.
>


If the traffic on bugtraq is any indication, writing in /tmp is a
security exposure for daemons. Typical attack is:

 ln -s /etc/passwd /tmp/dumbrootprog.tmpfile

when dumprootprog runs it writes on /etc/passwd. Cool huh? Not so serious
in our case, as only pgsql owned files are at risk, but why take a chance.
This argues for the private pid file.

Also, before sprinkling files all over it is good to try to conform
to the FHS (File Hierarchy Standard) (see http://www.pathname.com/fhs/)
which is pretty easy to do and likely to make life easier later.

-dg

David Gould            dg@informix.com           510.628.3783 or 510.305.9468
Informix Software  (No, really)         300 Lakeside Drive  Oakland, CA 94612
 - If simplicity worked, the world would be overrun with insects. -