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 ; 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 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 Status: RO Bruce Momjian 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 ; 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 ; 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 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 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 ; 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 ; 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 ; 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 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 Sender: owner-pgsql-hackers@hub.org Precedence: bulk Status: RO Massimo Dal Zotto 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 ; 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 ; 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 To: Tom Lane cc: Massimo Dal Zotto , PostgreSQL Hackers Subject: Re: [HACKERS] flock patch breaks things here In-Reply-To: <16092.904495855@sss.pgh.pa.us> Message-ID: 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 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 ; 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 ; 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 cc: PostgreSQL Hackers Subject: Re: [HACKERS] flock patch breaks things here In-reply-to: Your message of Sun, 30 Aug 1998 16:21:28 -0300 (ADT) Date: Sun, 30 Aug 1998 22:34:40 -0400 Message-ID: <20073.904530880@sss.pgh.pa.us> From: Tom Lane Sender: owner-pgsql-hackers@hub.org Precedence: bulk Status: ROr The Hermit Hacker 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 ; 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 ; 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 ; 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 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