--- /dev/null
+From tgl@sss.pgh.pa.us Sun Aug 30 11:25:23 1998
+Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6])
+ by candle.pha.pa.us (8.8.5/8.8.5) with ESMTP id LAA12607
+ for <maillist@candle.pha.pa.us>; Sun, 30 Aug 1998 11:25:20 -0400 (EDT)
+Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
+ by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id LAA15788;
+ Sun, 30 Aug 1998 11:23:38 -0400 (EDT)
+To: Bruce Momjian <maillist@candle.pha.pa.us>
+cc: dz@cs.unitn.it (Massimo Dal Zotto), hackers@postgreSQL.org
+Subject: Re: [HACKERS] flock patch breaks things here
+In-reply-to: Your message of Sun, 30 Aug 1998 08:19:52 -0400 (EDT)
+ <199808301219.IAA08821@candle.pha.pa.us>
+Date: Sun, 30 Aug 1998 11:23:38 -0400
+Message-ID: <15786.904490618@sss.pgh.pa.us>
+From: Tom Lane <tgl@sss.pgh.pa.us>
+Status: RO
+
+Bruce Momjian <maillist@candle.pha.pa.us> writes:
+> Can't we just have configure check for flock(). Another idea is to
+> create a 'pid' file in the pgsql/data/base directory, and do a kill -0
+> to see if it is stil running before removing the lock.
+
+The latter approach is what I was going to suggest. Writing a pid file
+would be a fine idea anyway --- for one thing, it makes it a lot easier
+to write a "kill the postmaster" script. Given that the postmaster
+should write a pid file, a new postmaster should look for an existing
+pid file, and try to do a kill(pid, 0) on the number contained therein.
+If this doesn't return an error, then you figure there is already a
+postmaster running, complain, and exit. Otherwise you figure you is it,
+(re)write the pid file and away you go. Then pqcomm.c can just
+unconditionally delete any old file that's in the way of making the
+pipe.
+
+The pidfile checking and creation probably ought to go in postmaster.c,
+not down inside pqcomm.c. I never liked the fact that a critical
+interlock function was being done by a low-level library that one might
+not even want to invoke (if all your clients are using TCP, opening up
+the Unix-domain socket is a waste of time, no?).
+
+BTW, there is another problem with relying on flock on the socket file
+for this purpose: it opens up a hole for a denial-of-service attack.
+Anyone who can write the file can flock it. (We already had a problem
+with DOS via creating a dummy file at /tmp/.s.PGSQL.5432, but it would
+be harder to spot the culprit with an flock-based interference.)
+
+ regards, tom lane
+
+From owner-pgsql-hackers@hub.org Sun Aug 30 12:27:41 1998
+Received: from hub.org (hub.org [209.47.148.200])
+ by candle.pha.pa.us (8.8.5/8.8.5) with ESMTP id MAA12976
+ for <maillist@candle.pha.pa.us>; Sun, 30 Aug 1998 12:27:37 -0400 (EDT)
+Received: from localhost (majordom@localhost) by hub.org (8.8.8/8.7.5) with SMTP id MAA09234; Sun, 30 Aug 1998 12:24:51 -0400 (EDT)
+Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Sun, 30 Aug 1998 12:23:26 +0000 (EDT)
+Received: (from majordom@localhost) by hub.org (8.8.8/8.7.5) id MAA09167 for pgsql-hackers-outgoing; Sun, 30 Aug 1998 12:23:25 -0400 (EDT)
+Received: from mambo.cs.unitn.it (mambo.cs.unitn.it [193.205.199.204]) by hub.org (8.8.8/8.7.5) with SMTP id MAA09150 for <hackers@postgreSQL.org>; Sun, 30 Aug 1998 12:23:08 -0400 (EDT)
+Received: from boogie.cs.unitn.it (dz@boogie [193.205.199.79]) by mambo.cs.unitn.it (8.6.12/8.6.12) with ESMTP id SAA29572; Sun, 30 Aug 1998 18:21:42 +0200
+Received: (from dz@localhost) by boogie.cs.unitn.it (8.8.5/8.6.9) id SAA05993; Sun, 30 Aug 1998 18:21:41 +0200
+From: Massimo Dal Zotto <dz@cs.unitn.it>
+Message-Id: <199808301621.SAA05993@boogie.cs.unitn.it>
+Subject: Re: [HACKERS] flock patch breaks things here
+To: hackers@postgreSQL.org (PostgreSQL Hackers)
+Date: Sun, 30 Aug 1998 18:21:41 +0200 (MET DST)
+Cc: tgl@sss.pgh.pa.us (Tom Lane)
+In-Reply-To: <15786.904490618@sss.pgh.pa.us> from "Tom Lane" at Aug 30, 98 11:23:38 am
+X-Mailer: ELM [version 2.4 PL24 ME4]
+MIME-Version: 1.0
+Content-Type: text/plain; charset=iso-8859-1
+Content-Transfer-Encoding: 8bit
+Sender: owner-pgsql-hackers@hub.org
+Precedence: bulk
+Status: ROr
+
+>
+> Bruce Momjian <maillist@candle.pha.pa.us> writes:
+> > Can't we just have configure check for flock(). Another idea is to
+> > create a 'pid' file in the pgsql/data/base directory, and do a kill -0
+> > to see if it is stil running before removing the lock.
+>
+> The latter approach is what I was going to suggest. Writing a pid file
+> would be a fine idea anyway --- for one thing, it makes it a lot easier
+> to write a "kill the postmaster" script. Given that the postmaster
+> should write a pid file, a new postmaster should look for an existing
+> pid file, and try to do a kill(pid, 0) on the number contained therein.
+> If this doesn't return an error, then you figure there is already a
+> postmaster running, complain, and exit. Otherwise you figure you is it,
+> (re)write the pid file and away you go. Then pqcomm.c can just
+> unconditionally delete any old file that's in the way of making the
+> pipe.
+>
+> The pidfile checking and creation probably ought to go in postmaster.c,
+> not down inside pqcomm.c. I never liked the fact that a critical
+> interlock function was being done by a low-level library that one might
+> not even want to invoke (if all your clients are using TCP, opening up
+> the Unix-domain socket is a waste of time, no?).
+>
+> BTW, there is another problem with relying on flock on the socket file
+> for this purpose: it opens up a hole for a denial-of-service attack.
+> Anyone who can write the file can flock it. (We already had a problem
+> with DOS via creating a dummy file at /tmp/.s.PGSQL.5432, but it would
+> be harder to spot the culprit with an flock-based interference.)
+
+This came to my mind, but I didn't think this would have happened so
+quickly. In my opinion the socket and the pidfile should be created in a
+directory owned by postgres, for example /tmp/.Pgsql-unix, like does X.
+
+--
+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 |
++----------------------------------------------------------------------+
+
+
+From owner-pgsql-hackers@hub.org Sun Aug 30 13:01:10 1998
+Received: from renoir.op.net (root@renoir.op.net [209.152.193.4])
+ by candle.pha.pa.us (8.8.5/8.8.5) with ESMTP id NAA13785
+ for <maillist@candle.pha.pa.us>; Sun, 30 Aug 1998 13:01:09 -0400 (EDT)
+Received: from hub.org (hub.org [209.47.148.200]) by renoir.op.net (o1/$ Revision: 1.18 $) with ESMTP id MAA29386 for <maillist@candle.pha.pa.us>; Sun, 30 Aug 1998 12:58:24 -0400 (EDT)
+Received: from localhost (majordom@localhost) by hub.org (8.8.8/8.7.5) with SMTP id MAA11406; Sun, 30 Aug 1998 12:54:48 -0400 (EDT)
+Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Sun, 30 Aug 1998 12:52:22 +0000 (EDT)
+Received: (from majordom@localhost) by hub.org (8.8.8/8.7.5) id MAA11310 for pgsql-hackers-outgoing; Sun, 30 Aug 1998 12:52:20 -0400 (EDT)
+Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by hub.org (8.8.8/8.7.5) with ESMTP id MAA11296 for <hackers@postgreSQL.org>; Sun, 30 Aug 1998 12:52:13 -0400 (EDT)
+Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
+ by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id MAA16094;
+ Sun, 30 Aug 1998 12:50:55 -0400 (EDT)
+To: Massimo Dal Zotto <dz@cs.unitn.it>
+cc: hackers@postgreSQL.org (PostgreSQL Hackers)
+Subject: Re: [HACKERS] flock patch breaks things here
+In-reply-to: Your message of Sun, 30 Aug 1998 18:21:41 +0200 (MET DST)
+ <199808301621.SAA05993@boogie.cs.unitn.it>
+Date: Sun, 30 Aug 1998 12:50:55 -0400
+Message-ID: <16092.904495855@sss.pgh.pa.us>
+From: Tom Lane <tgl@sss.pgh.pa.us>
+Sender: owner-pgsql-hackers@hub.org
+Precedence: bulk
+Status: RO
+
+Massimo Dal Zotto <dz@cs.unitn.it> writes:
+> In my opinion the socket and the pidfile should be created in a
+> directory owned by postgres, for example /tmp/.Pgsql-unix, like does X.
+
+The pidfile belongs at the top level of the database directory (eg,
+/usr/local/pgsql/data/postmaster.pid), because what it actually
+represents is that there is a postmaster running *for that database
+group*.
+
+If you want to support multiple database sets on one machine (which I
+do), then the interlock has to be per database directory. Putting the
+pidfile into a common directory would mean we'd have to invent some
+kind of pidfile naming convention to keep multiple postmasters from
+tromping on each other. This is unnecessarily complex.
+
+I agree with you that putting the socket file into a less easily munged
+directory than /tmp would be a good idea for security. But that's a
+separate issue. On machines that understand stickybits for directories,
+the security hole is not really very big.
+
+At this point, the fact that /tmp/.s.PGSQL.port# is the socket path is
+effectively a version-independent aspect of the FE/BE protocol, and so
+we can't change it without breaking old applications. I'm not sure that
+that's worth the security improvement.
+
+What I'd like to see someday is a postmaster command line switch to tell
+it to use *only* TCP connections and not create a Unix socket at all.
+That hasn't been possible so far, because we were relying on the socket
+file to provide a safety interlock against starting multiple
+postmasters. But an interlock using a pidfile would be much better.
+(Look around; *every* other Unix daemon I know of that wants to ensure
+that there's only one of it uses a pidfile interlock. Not file locking.
+There's a reason why that's the well-trodden path.)
+
+ regards, tom lane
+
+
+From owner-pgsql-hackers@hub.org Sun Aug 30 15:31:13 1998
+Received: from hub.org (hub.org [209.47.148.200])
+ by candle.pha.pa.us (8.8.5/8.8.5) with ESMTP id PAA15275
+ for <maillist@candle.pha.pa.us>; Sun, 30 Aug 1998 15:31:11 -0400 (EDT)
+Received: from localhost (majordom@localhost) by hub.org (8.8.8/8.7.5) with SMTP id PAA22194; Sun, 30 Aug 1998 15:27:20 -0400 (EDT)
+Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Sun, 30 Aug 1998 15:23:58 +0000 (EDT)
+Received: (from majordom@localhost) by hub.org (8.8.8/8.7.5) id PAA21800 for pgsql-hackers-outgoing; Sun, 30 Aug 1998 15:23:57 -0400 (EDT)
+Received: from thelab.hub.org (nat0118.mpoweredpc.net [142.177.188.118]) by hub.org (8.8.8/8.7.5) with ESMTP id PAA21696 for <hackers@postgreSQL.org>; Sun, 30 Aug 1998 15:22:51 -0400 (EDT)
+Received: from localhost (scrappy@localhost)
+ by thelab.hub.org (8.9.1/8.8.8) with SMTP id QAA18542;
+ Sun, 30 Aug 1998 16:21:29 -0300 (ADT)
+ (envelope-from scrappy@hub.org)
+X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
+Date: Sun, 30 Aug 1998 16:21:28 -0300 (ADT)
+From: The Hermit Hacker <scrappy@hub.org>
+To: Tom Lane <tgl@sss.pgh.pa.us>
+cc: Massimo Dal Zotto <dz@cs.unitn.it>,
+ PostgreSQL Hackers <hackers@postgreSQL.org>
+Subject: Re: [HACKERS] flock patch breaks things here
+In-Reply-To: <16092.904495855@sss.pgh.pa.us>
+Message-ID: <Pine.BSF.4.02.9808301618350.343-100000@thelab.hub.org>
+MIME-Version: 1.0
+Content-Type: TEXT/PLAIN; charset=US-ASCII
+Sender: owner-pgsql-hackers@hub.org
+Precedence: bulk
+Status: RO
+
+On Sun, 30 Aug 1998, Tom Lane wrote:
+
+> Massimo Dal Zotto <dz@cs.unitn.it> writes:
+> > In my opinion the socket and the pidfile should be created in a
+> > directory owned by postgres, for example /tmp/.Pgsql-unix, like does X.
+>
+> The pidfile belongs at the top level of the database directory (eg,
+> /usr/local/pgsql/data/postmaster.pid), because what it actually
+> represents is that there is a postmaster running *for that database
+> group*.
+
+ I have to agree with this one...but then it also negates the
+argument about the flock() DoS...*grin*
+
+ BTW...I like the kill(pid,0) solution myself, primarily because it
+is, i think, the most portable solution.
+
+ I would not consider a patch to remove the flock() solution and
+replace it with the kill(pid,0) solution a new feature, just an
+improvement of an existing one...either way, moving the pid file (or
+socket, for that matter) from /tmp should be listed as a security related
+requirement for v6.4 :)
+
+Marc G. Fournier
+Systems Administrator @ hub.org
+primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
+
+
+
+From owner-pgsql-hackers@hub.org Sun Aug 30 22:41:10 1998
+Received: from hub.org (hub.org [209.47.148.200])
+ by candle.pha.pa.us (8.8.5/8.8.5) with ESMTP id WAA01526
+ for <maillist@candle.pha.pa.us>; Sun, 30 Aug 1998 22:41:08 -0400 (EDT)
+Received: from localhost (majordom@localhost) by hub.org (8.8.8/8.7.5) with SMTP id WAA29298; Sun, 30 Aug 1998 22:38:18 -0400 (EDT)
+Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Sun, 30 Aug 1998 22:35:05 +0000 (EDT)
+Received: (from majordom@localhost) by hub.org (8.8.8/8.7.5) id WAA29203 for pgsql-hackers-outgoing; Sun, 30 Aug 1998 22:35:03 -0400 (EDT)
+Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by hub.org (8.8.8/8.7.5) with ESMTP id WAA29017 for <hackers@postgreSQL.org>; Sun, 30 Aug 1998 22:34:55 -0400 (EDT)
+Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
+ by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id WAA20075;
+ Sun, 30 Aug 1998 22:34:41 -0400 (EDT)
+To: The Hermit Hacker <scrappy@hub.org>
+cc: PostgreSQL Hackers <hackers@postgreSQL.org>
+Subject: Re: [HACKERS] flock patch breaks things here
+In-reply-to: Your message of Sun, 30 Aug 1998 16:21:28 -0300 (ADT)
+ <Pine.BSF.4.02.9808301618350.343-100000@thelab.hub.org>
+Date: Sun, 30 Aug 1998 22:34:40 -0400
+Message-ID: <20073.904530880@sss.pgh.pa.us>
+From: Tom Lane <tgl@sss.pgh.pa.us>
+Sender: owner-pgsql-hackers@hub.org
+Precedence: bulk
+Status: ROr
+
+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
+
+
+From owner-pgsql-hackers@hub.org Mon Aug 31 11:31:19 1998
+Received: from renoir.op.net (root@renoir.op.net [209.152.193.4])
+ by candle.pha.pa.us (8.8.5/8.8.5) with ESMTP id LAA21195
+ for <maillist@candle.pha.pa.us>; Mon, 31 Aug 1998 11:31:13 -0400 (EDT)
+Received: from hub.org (hub.org [209.47.148.200]) by renoir.op.net (o1/$ Revision: 1.18 $) with ESMTP id LAA06827 for <maillist@candle.pha.pa.us>; Mon, 31 Aug 1998 11:17:41 -0400 (EDT)
+Received: from localhost (majordom@localhost) by hub.org (8.8.8/8.7.5) with SMTP id LAA24792; Mon, 31 Aug 1998 11:12:18 -0400 (EDT)
+Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Mon, 31 Aug 1998 11:10:31 +0000 (EDT)
+Received: (from majordom@localhost) by hub.org (8.8.8/8.7.5) id LAA24742 for pgsql-hackers-outgoing; Mon, 31 Aug 1998 11:10:29 -0400 (EDT)
+Received: from trillium.nmsu.edu (trillium.NMSU.Edu [128.123.5.15]) by hub.org (8.8.8/8.7.5) with ESMTP id LAA24725 for <hackers@postgreSQL.org>; Mon, 31 Aug 1998 11:10:22 -0400 (EDT)
+Received: (from brook@localhost)
+ by trillium.nmsu.edu (8.8.8/8.8.8) id JAA03282;
+ Mon, 31 Aug 1998 09:09:01 -0600 (MDT)
+Date: Mon, 31 Aug 1998 09:09:01 -0600 (MDT)
+Message-Id: <199808311509.JAA03282@trillium.nmsu.edu>
+From: Brook Milligan <brook@trillium.NMSU.Edu>
+To: tgl@sss.pgh.pa.us
+CC: dg@informix.com, hackers@postgreSQL.org
+In-reply-to: <23042.904573041@sss.pgh.pa.us> (message from Tom Lane on Mon, 31
+ Aug 1998 10:17:21 -0400)
+Subject: Re: [HACKERS] flock patch breaks things here
+References: <23042.904573041@sss.pgh.pa.us>
+Sender: owner-pgsql-hackers@hub.org
+Precedence: bulk
+Status: ROr
+
+ I just came up with an idea that might help alleviate the /tmp security
+ exposure without creating a backwards-compatibility problem. It works
+ like this:
+
+ 1. During installation, create a subdirectory of /tmp to hold Postgres'
+ socket files and associated pid lockfiles. This subdirectory should be
+ owned by the Postgres superuser and have permissions 755
+ (world-readable, writable only by Postgres superuser). Maybe call it
+ /tmp/.pgsql --- the name should start with a dot to keep it out of the
+ way. (Bruce points out that some systems clear /tmp during reboot, so
+ it might be that a postmaster will have to be prepared to recreate this
+ directory at startup --- anyone know if subdirectories of /tmp are
+ zapped too? My system doesn't do that...)
+
+ ...
+
+ I notice that on my system, the X11 socket files in /tmp/.X11-unix are
+ actually symlinks to socket files in /usr/spool/sockets/X11. I dunno if
+ it's worth our trouble to get into putting our sockets under /usr/spool
+ or /var/spool or whatever --- seems like another configuration choice to
+ mess up. It'd be nice if the socket directory lived somewhere where the
+ parent dirs weren't world-writable, but this would mean one more thing
+ that you have to have root permissions for in order to install pgsql.
+
+It seems like we need a directory for locks (= pid files) and one for
+sockets (perhaps the same one). I strongly suggest that the location
+for these be configurable. By default, it might make sense to put
+them in ~pgsql/locks and ~pgsql/sockets. It is easy (i.e., I'll be
+glad to do it) to modify configure.in to take options like
+
+ --lock-dir=/var/spool/lock
+ --socket-dir=/var/spool/sockets
+
+that set cc defines and have the code respond accordingly. This way,
+those who don't care (or don't have root access) can use the defaults,
+whereas those with root access who like to keep locks and sockets in a
+common place can do so easily. Either way, multiple postmasters (all
+compiled with the same options of course) can check the appropriate
+locks in the well-known places. Finally, drop the link into /tmp for
+the old socket and document that it will be disappearing at some
+point, and all is fine.
+
+If someone wants to give me some guidance on what preprocessor
+variables should be set in response to the above options (or something
+like them), I'll do the configure stuff.
+
+Cheers,
+Brook
+
+
projects / postgresql / commitdiff