diff options
Diffstat (limited to 'doc/TODO.detail/flock')
| -rw-r--r-- | doc/TODO.detail/flock | 351 |
1 files changed, 0 insertions, 351 deletions
diff --git a/doc/TODO.detail/flock b/doc/TODO.detail/flock deleted file mode 100644 index 93d4e18e43d..00000000000 --- a/doc/TODO.detail/flock +++ /dev/null @@ -1,351 +0,0 @@ -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 - - |