Thread
-
Re: [HACKERS] flock patch breaks things here
Tom Lane <tgl@sss.pgh.pa.us> — 1998-08-31T02:34:40Z
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. regards, tom lane
-
Re: [HACKERS] flock patch breaks things here
Bruce Momjian <maillist@candle.pha.pa.us> — 1998-08-31T04:36:34Z
> 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. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
-
Re: [HACKERS] flock patch breaks things here
David Gould <dg@informix.com> — 1998-08-31T08:23:02Z
> > > 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. -
-
Re: [HACKERS] flock patch breaks things here
Marc Fournier <scrappy@hub.org> — 1998-08-31T12:24:46Z
On Mon, 31 Aug 1998, David Gould wrote: > 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. I just downloaded and skim'd the fhs notes, and it looks reasonable...but, other then the current socket in /tmp, we don't "splinkle files all over"...do we? *raised eyebrow*
-
Re: [HACKERS] flock patch breaks things here
David Gould <dg@informix.com> — 1998-08-31T17:49:10Z
> > On Mon, 31 Aug 1998, David Gould wrote: > > > 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. > > I just downloaded and skim'd the fhs notes, and it looks > reasonable...but, other then the current socket in /tmp, we don't > "splinkle files all over"...do we? *raised eyebrow* > Well, perhaps not, thay might have been hyperbole, but I wanted to head it off before it happened. Also, what about moving the socket to the PG_DATA dir and then creating a symlink to it in /tmp for older clients. New installations could optionally not create (or remove) the symlink... -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. -
-
Re: [HACKERS] flock patch breaks things here
Bruce Momjian <maillist@candle.pha.pa.us> — 1998-08-31T18:06:48Z
> > > > On Mon, 31 Aug 1998, David Gould wrote: > > > > > 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. > > > > I just downloaded and skim'd the fhs notes, and it looks > > reasonable...but, other then the current socket in /tmp, we don't > > "splinkle files all over"...do we? *raised eyebrow* > > > > Well, perhaps not, thay might have been hyperbole, but I wanted to head it > off before it happened. > > Also, what about moving the socket to the PG_DATA dir and then creating a > symlink to it in /tmp for older clients. New installations could optionally > not create (or remove) the symlink... But then we have to compile the data directory into the client, or add an option to specify the unix domain socket AND the data directory. Not worth it, I think. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
-
Re: [HACKERS] flock patch breaks things here
Massimo Dal Zotto <dz@cs.unitn.it> — 1998-08-31T21:02:51Z
> > > > > On Mon, 31 Aug 1998, David Gould wrote: > > > > > 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. > > > > I just downloaded and skim'd the fhs notes, and it looks > > reasonable...but, other then the current socket in /tmp, we don't > > "splinkle files all over"...do we? *raised eyebrow* > > > > Well, perhaps not, thay might have been hyperbole, but I wanted to head it > off before it happened. > > Also, what about moving the socket to the PG_DATA dir and then creating a > symlink to it in /tmp for older clients. New installations could optionally > not create (or remove) the symlink... > > -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. - In the fhs notes I read: ------------------------------------------------------------------------ 5.9 /var/run : Run-time variable files This directory contains system information files describing the system since it was booted. Files in this directory should be cleared (removed or truncated as appropriate) at the beginning of the boot process. Process identifier (PID) files, which were originally placed in /etc, should be placed in /var/run. The naming convention for PID files is <program-name>.pid. For example, the crond PID file is named /var/run/crond.pid. The internal format of PID files remains unchanged. The file should consist of the process identifier in ASCII-encoded decimal, followed by a newline character. For example, if crond was process number 25, /var/run/crond.pid would contain three characters: two, five, and newline. Programs that read PID files should be somewhat flexible in what they accept; i.e., they should ignore extra whitespace, leading zeroes, absence of the trailing newline, or additional lines in the PID file. Programs that create PID files should use the simple specification located in the above paragraph. The utmp file, which stores information about who is currently using the system, is located in this directory. Programs that maintain transient UNIX-domain sockets should place them in this directory. ------------------------------------------------------------------------ It seems that if we want to follow this document there is no much to discuss. But on my linux installation this directory is owned by root so I don't see how pgsql could create a socket in it. What standards are in use on other systems ? -- Massimo Dal Zotto +----------------------------------------------------------------------+ | Massimo Dal Zotto email: dz@cs.unitn.it | | Via Marconi, 141 phone: ++39-461-534251 | | 38057 Pergine Valsugana (TN) www: http://www.cs.unitn.it/~dz/ | | Italy pgp: finger dz@tango.cs.unitn.it | +----------------------------------------------------------------------+
-
Re: [HACKERS] flock patch breaks things here
Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-09-01T01:38:19Z
> Also, what about moving the socket to the PG_DATA dir and then > creating a symlink to it in /tmp for older clients. Clients don't have visibility into $PG_DATA, do they? Just ran into this working on the ODBC interface, trying to find a place for a system-wide configuration file. Ended up putting it in $POSTGRESDIR by default. The /var/run option (or something similar) seems to be a good way to head, if we can get enough support on the different platforms. Actually, this could be an autoconf test, couldn't it? - Thomas -
Re: [HACKERS] flock patch breaks things here
Marc Fournier <scrappy@hub.org> — 1998-10-30T02:11:02Z
On Sun, 30 Aug 1998, Tom Lane wrote: > 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. Let me put my vote in...: $PGSQLHOME/run/{pgsql.pid,pgsql.pid.socket} Screw backwards compatibility...v6.5 becomes v7.0 *shrug* Marc G. Fournier Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org