From d0cb4e11d552413afcdb11ff1009293c4a3ea776 Mon Sep 17 00:00:00 2001 From: Bruce Momjian Date: Wed, 5 Jul 2000 04:39:15 +0000 Subject: [PATCH] U Re-add flock TODO.detail. --- doc/TODO.detail/flock | 351 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 351 insertions(+) create mode 100644 doc/TODO.detail/flock diff --git a/doc/TODO.detail/flock b/doc/TODO.detail/flock new file mode 100644 index 0000000000..93d4e18e43 --- /dev/null +++ b/doc/TODO.detail/flock @@ -0,0 +1,351 @@ +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 + +