From: | dg(at)informix(dot)com (David Gould) |
---|---|
To: | maillist(at)candle(dot)pha(dot)pa(dot)us (Bruce Momjian) |
Cc: | tgl(at)sss(dot)pgh(dot)pa(dot)us, scrappy(at)hub(dot)org, hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] flock patch breaks things here |
Date: | 1998-08-31 08:23:02 |
Message-ID: | 9808310823.AA12647@hawk.oak.informix.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>
> > The Hermit Hacker <scrappy(at)hub(dot)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(at)informix(dot)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. -
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 1998-08-31 09:15:29 | LinuxPPC problems |
Previous Message | David Gould | 1998-08-31 08:13:55 | Re: [HACKERS] other changes |