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