postmaster crash and .s.pgsql file

On Mon, 26 Jan 1998, Bruce Momjian wrote:

When the postmaster crashes, it leaves the /tmp/.s.pgsql file in /tmp.
Is there a way to auto-remove it after a postmaster crash?

If we wrote the process id to the file, if the file existed, we
could read the process id and do a 'kill(pid, 0)', it "determines if a
specific process still exists"...

I'll try and look at it tonight, along with syslog() logging

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

On Mon, 26 Jan 1998, The Hermit Hacker wrote:

On Mon, 26 Jan 1998, Bruce Momjian wrote:

When the postmaster crashes, it leaves the /tmp/.s.pgsql file in /tmp.
Is there a way to auto-remove it after a postmaster crash?

If we wrote the process id to the file, if the file existed, we
could read the process id and do a 'kill(pid, 0)', it "determines if a
specific process still exists"...

I'll try and look at it tonight, along with syslog() logging

Oops...I screwed up *rofl* I wasn't thinking when I wrote
this...I was thining that /tmp/.s.PGSQL was a lock file...I forgot it was
a socket :( forget me thing about the kill :) I haven't got a clue how
to detect whether it is active or not :(

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

On Mon, 26 Jan 1998, Bruce Momjian wrote:

:
: When the postmaster crashes, it leaves the /tmp/.s.pgsql file in /tmp.
: Is there a way to auto-remove it after a postmaster crash?
:
: --
: Bruce Momjian
: maillist@candle.pha.pa.us
:

I found that when using "-S" with postmaster, the file doesn't get
created at all. I will look at removing the file on startup when I'm in
there.

-James

On Mon, 26 Jan 1998, Bruce Momjian wrote:

:
: When the postmaster crashes, it leaves the /tmp/.s.pgsql file in /tmp.
: Is there a way to auto-remove it after a postmaster crash?
:
: --
: Bruce Momjian
: maillist@candle.pha.pa.us
:

I found that when using "-S" with postmaster, the file doesn't get
created at all.

I have submitted a patch for this before,
I think a got applied, maybe it has been
(accidently) reverted since.
(patch below)

The same goes for Bruce's problem with
socket name being 1 char short.

I will look at removing the file on startup when I'm in there.

Don't, it gets removed at shutdown except when crashing.
Removing at startup opens a whole new can of worms.
(You must no postmaster is not already running.)

regards,
--
---------------------------------------------
G�ran Thyni, sysadm, JMS Bildbasen, Kiruna

------------------ snip -----------------------------------

diff -c src/backend/postmaster/postmaster.c.orig src/backend/postmaster/postmaster.c
*** /databaser/pg-sup/pgsql/src/backend/postmaster/postmaster.c.orig	Mon Jan 26 08:46:08 1998
--- /databaser/pg-sup/pgsql/src/backend/postmaster/postmaster.c	Tue Jan 27 09:35:21 1998
***************
*** 482,488 ****
  	{
  		fprintf(stderr, "%s: ", progname);
  		perror("cannot disassociate from controlling TTY");
! 		exit(1);
  	}
  #endif
  	i = open(NULL_DEV, O_RDWR);
--- 482,488 ----
  	{
  		fprintf(stderr, "%s: ", progname);
  		perror("cannot disassociate from controlling TTY");
! 		_exit(1);
  	}
  #endif
  	i = open(NULL_DEV, O_RDWR);

Sorry,
last patch wrong.
This is the right one:

diff -c src/backend/postmaster/postmaster.c.orig src/backend/postmaster/postmaster.c
*** src/backend/postmaster/postmaster.c.orig	Mon Jan 26 08:46:08 1998
--- src/backend/postmaster/postmaster.c	Tue Jan 27 09:37:45 1998
***************
*** 473,479 ****
  	int			i;

  	if (fork())
! 		exit(0);
  /* GH: If there's no setsid(), we hopefully don't need silent mode.
   * Until there's a better solution.
   */
--- 473,479 ----
  	int			i;

if (fork())
! _exit(0);
/* GH: If there's no setsid(), we hopefully don't need silent mode.
* Until there's a better solution.
*/

On 27 Jan 1998, Goran Thyni wrote:

:
: On Mon, 26 Jan 1998, Bruce Momjian wrote:
:
: :
: : When the postmaster crashes, it leaves the /tmp/.s.pgsql file in /tmp.
: : Is there a way to auto-remove it after a postmaster crash?
: :

<snip>

: I will look at removing the file on startup when I'm in there.
:
: Don't, it gets removed at shutdown except when crashing.
: Removing at startup opens a whole new can of worms.
: (You must no postmaster is not already running.)
:

How about in postmaster.c (arround line 427), when starting up...

1.) Check for the existence of a pid file.

2.) If one is there, read the pid and see if a back end is alive.

3.) If so, warn the user and exit.

4.) If not, check for and cleanup any leftover files.

5.) Continue with startup process.

...wouldn't this work OK?

-James

On Mon, 26 Jan 1998, Bruce Momjian wrote:

:
: When the postmaster crashes, it leaves the /tmp/.s.pgsql file in /tmp.
: Is there a way to auto-remove it after a postmaster crash?
:
: --
: Bruce Momjian
: maillist@candle.pha.pa.us
:

I found that when using "-S" with postmaster, the file doesn't get
created at all.

I have submitted a patch for this before,
I think a got applied, maybe it has been
(accidently) reverted since.
(patch below)

The same goes for Bruce's problem with
socket name being 1 char short.

I will look at removing the file on startup when I'm in there.

Don't, it gets removed at shutdown except when crashing.
Removing at startup opens a whole new can of worms.
(You must no postmaster is not already running.)

Yes. All is working, thanks.

--
Bruce Momjian
maillist@candle.pha.pa.us

: Removing at startup opens a whole new can of worms.
: (You must no postmaster is not already running.)

How about in postmaster.c (arround line 427), when starting up...
1.) Check for the existence of a pid file.
2.) If one is there, read the pid and see if a back end is alive.
3.) If so, warn the user and exit.
4.) If not, check for and cleanup any leftover files.
5.) Continue with startup process.
...wouldn't this work OK?

It would,
but it would be complex.

The easy way to check for a pid is "kill -0 PID".
But...
It only works if we are running under the same user
as the server (or root).

Besides,
we do not know that a process running as that
pid really is a postmaster w/o checking the process
table - and that is "portability hell".

Besides 2,
how do get the pid in the first place?
If you code it into the socket, like:
/tmp/.s.PORTNR.PID
how would the clients find the socket to connect to?
(they do not know the pid of the server)

Better leave it until after 6.3 (at least).

best regards,
--
---------------------------------------------
G�ran Thyni, sysadm, JMS Bildbasen, Kiruna

Sorry,
last patch wrong.
This is the right one:

Applied. I don't know what other patch you are mentioning.

diff -c src/backend/postmaster/postmaster.c.orig src/backend/postmaster/postmaster.c
*** src/backend/postmaster/postmaster.c.orig	Mon Jan 26 08:46:08 1998
--- src/backend/postmaster/postmaster.c	Tue Jan 27 09:37:45 1998
***************
*** 473,479 ****
int			i;

if (fork())
! 		exit(0);
/* GH: If there's no setsid(), we hopefully don't need silent mode.
* Until there's a better solution.
*/
--- 473,479 ----
int			i;

if (fork())
! _exit(0);
/* GH: If there's no setsid(), we hopefully don't need silent mode.
* Until there's a better solution.
*/

--
Bruce Momjian
maillist@candle.pha.pa.us

On Tue, 27 Jan 1998, James Hughes wrote:

On 27 Jan 1998, Goran Thyni wrote:

:
: On Mon, 26 Jan 1998, Bruce Momjian wrote:
:
: :
: : When the postmaster crashes, it leaves the /tmp/.s.pgsql file in /tmp.
: : Is there a way to auto-remove it after a postmaster crash?
: :

<snip>

: I will look at removing the file on startup when I'm in there.
:
: Don't, it gets removed at shutdown except when crashing.
: Removing at startup opens a whole new can of worms.
: (You must no postmaster is not already running.)
:

How about in postmaster.c (arround line 427), when starting up...

1.) Check for the existence of a pid file.

2.) If one is there, read the pid and see if a back end is alive.

3.) If so, warn the user and exit.

4.) If not, check for and cleanup any leftover files.

5.) Continue with startup process.

...wouldn't this work OK?

A thought. Why not change the startup routine such that instead
of creating /tmp/.s.PGSQL.5432, create a subdirectory that contains both
the socket (.socket) and the PID file? Given time, I could see us adding
in some stats to the postmaster process, similar to named, where you
SIGUSR2 the process and it dumps a status file and that too could get
dumped there.

Just a thought...

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

A thought. Why not change the startup routine such that instead
of creating /tmp/.s.PGSQL.5432, create a subdirectory that contains both
the socket (.socket) and the PID file? Given time, I could see us adding
in some stats to the postmaster process, similar to named, where you
SIGUSR2 the process and it dumps a status file and that too could get
dumped there.

Just a thought...

Let's see what people report. With the bug fixed, I never see leftover
/tmp/.s.pgsql files.

--
Bruce Momjian
maillist@candle.pha.pa.us

On Tue, 27 Jan 1998, The Hermit Hacker wrote:

: On Tue, 27 Jan 1998, James Hughes wrote:
:
: > On 27 Jan 1998, Goran Thyni wrote:
: >
: > :
: > : On Mon, 26 Jan 1998, Bruce Momjian wrote:
: > :
: > : :
: > : : When the postmaster crashes, it leaves the /tmp/.s.pgsql file in /tmp.
: > : : Is there a way to auto-remove it after a postmaster crash?
: > : :
: >
: > <snip>
: >
: > : I will look at removing the file on startup when I'm in there.
: > :
: > : Don't, it gets removed at shutdown except when crashing.
: > : Removing at startup opens a whole new can of worms.
: > : (You must no postmaster is not already running.)
: > :
: >
: > How about in postmaster.c (arround line 427), when starting up...
: >
: > 1.) Check for the existence of a pid file.
: >
: > 2.) If one is there, read the pid and see if a back end is alive.
: >
: > 3.) If so, warn the user and exit.
: >
: > 4.) If not, check for and cleanup any leftover files.
: >
: > 5.) Continue with startup process.
: >
: > ...wouldn't this work OK?
:
: A thought. Why not change the startup routine such that instead
: of creating /tmp/.s.PGSQL.5432, create a subdirectory that contains both
: the socket (.socket) and the PID file? Given time, I could see us adding
: in some stats to the postmaster process, similar to named, where you
: SIGUSR2 the process and it dumps a status file and that too could get
: dumped there.
:
: Just a thought...
:

I would opt for /var/run to store the pid files and have the name set to
pgsql.$PORT. A ".pgsql" subdirectory in /tmp would be nice to store all
the sockets. You mentioned syslog capability in a previous message
and maybe an rc file is needed too...

I'm with Goran though, we should save these for one of the next
(6.3.[1-3]) releases.

-James

On Wed, 28 Jan 1998, James Hughes wrote:

I would opt for /var/run to store the pid files and have the name set to

That would assume that postmaster runs as root, which is not
allowed...has to be in /tmp somewhere

pgsql.$PORT. A ".pgsql" subdirectory in /tmp would be nice to store all
the sockets. You mentioned syslog capability in a previous message
and maybe an rc file is needed too...

I'm with Goran though, we should save these for one of the next
(6.3.[1-3]) releases.

Makes sense

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

I would opt for /var/run to store the pid files and have the name set to

That would assume that postmaster runs as root, which is not
allowed...has to be in /tmp somewhere

Maybe both should be under /usr/local/pgsql
somewhere, so they will not be removed by any
'/tmp'-clean-up-scripts.

Maybe we should move the socket there before 6.3.
I do not have the necessary time right now,
but I will look into it unless someone beats
me to the punch.

v�nliga h�lsningar,
--
---------------------------------------------
G�ran Thyni, sysadm, JMS Bildbasen, Kiruna

I would opt for /var/run to store the pid files and have the name set to

That would assume that postmaster runs as root, which is not
allowed...has to be in /tmp somewhere

Maybe both should be under /usr/local/pgsql

I assume you mean the root of the installation rather than specifically
/usr/local/pgsql.

somewhere, so they will not be removed by any
'/tmp'-clean-up-scripts.

In $PGDATA would seem as good as anywhere (maybe $PGDATA/.run or some such)

/usr/local is mounted r/o on my system - $PGDATA lives elsewhere and is
writable.

Andrew
----------------------------------------------------------------------------
Dr. Andrew C.R. Martin University College London
EMAIL: (Work) martin@biochem.ucl.ac.uk (Home) andrew@stagleys.demon.co.uk
URL: http://www.biochem.ucl.ac.uk/~martin
Tel: (Work) +44(0)171 419 3890 (Home) +44(0)1372 275775

On 29 Jan 1998, Goran Thyni wrote:

I would opt for /var/run to store the pid files and have the name set to

That would assume that postmaster runs as root, which is not
allowed...has to be in /tmp somewhere

Maybe both should be under /usr/local/pgsql
somewhere, so they will not be removed by any
'/tmp'-clean-up-scripts.

I don't agree with this either.../tmp is world
readable/writable...what happens if 'joe blow user' decides for whatever
reason to initdb a database in his personal directory space and run a
postmaster process of his own? (S)he'd be running the same system binary,
just under her own userid...

On Thu, 29 Jan 1998, Andrew Martin wrote:

I would opt for /var/run to store the pid files and have the name set to

That would assume that postmaster runs as root, which is not
allowed...has to be in /tmp somewhere

Maybe both should be under /usr/local/pgsql

I assume you mean the root of the installation rather than specifically
/usr/local/pgsql.

somewhere, so they will not be removed by any
'/tmp'-clean-up-scripts.

In $PGDATA would seem as good as anywhere (maybe $PGDATA/.run or some such)

/usr/local is mounted r/o on my system - $PGDATA lives elsewhere and is
writable.

$PGDATA is created 700...general users need to be able to read the
directory in order to connect to the socket, so we'd have to lax up
security in order to accomplish this...

On Thu, 29 Jan 1998, Andrew Martin wrote:

I would opt for /var/run to store the pid files and have the name set to

That would assume that postmaster runs as root, which is not
allowed...has to be in /tmp somewhere

Maybe both should be under /usr/local/pgsql

I assume you mean the root of the installation rather than specifically
/usr/local/pgsql.

somewhere, so they will not be removed by any
'/tmp'-clean-up-scripts.

In $PGDATA would seem as good as anywhere (maybe $PGDATA/.run or some such)

/usr/local is mounted r/o on my system - $PGDATA lives elsewhere and is
writable.

$PGDATA is created 700...general users need to be able to read the
directory in order to connect to the socket, so we'd have to lax up
security in order to accomplish this...

OK, no problem, a subdirectory of $PGDATA which has world read permission

Andrew

----------------------------------------------------------------------------
Dr. Andrew C.R. Martin University College London
EMAIL: (Work) martin@biochem.ucl.ac.uk (Home) andrew@stagleys.demon.co.uk
URL: http://www.biochem.ucl.ac.uk/~martin
Tel: (Work) +44(0)171 419 3890 (Home) +44(0)1372 275775

On Thu, 29 Jan 1998, Andrew Martin wrote:

On Thu, 29 Jan 1998, Andrew Martin wrote:

I would opt for /var/run to store the pid files and have the name set to

That would assume that postmaster runs as root, which is not
allowed...has to be in /tmp somewhere

Maybe both should be under /usr/local/pgsql

I assume you mean the root of the installation rather than specifically
/usr/local/pgsql.

somewhere, so they will not be removed by any
'/tmp'-clean-up-scripts.

In $PGDATA would seem as good as anywhere (maybe $PGDATA/.run or some such)

/usr/local is mounted r/o on my system - $PGDATA lives elsewhere and is
writable.

$PGDATA is created 700...general users need to be able to read the
directory in order to connect to the socket, so we'd have to lax up
security in order to accomplish this...

OK, no problem, a subdirectory of $PGDATA which has world read permission

You'd have to relax the 700 permissions on $PGDATA to get at
anything under that directory, even if the subdirectory under it had 777
access to it...

And, it also makes the assumption that you'll only ever have 1
postmaster process running on a machine, or else you are now having to set
the PGDATA environment variable depending on which database you want to
connect to...:(

On Thu, 29 Jan 1998, Andrew Martin wrote:

: > On Thu, 29 Jan 1998, Andrew Martin wrote:
: >
: > > > > I would opt for /var/run to store the pid files and have the name set to
: > > >
: > > > That would assume that postmaster runs as root, which is not
: > > > allowed...has to be in /tmp somewhere
: > > >
: > > > Maybe both should be under /usr/local/pgsql
: > > I assume you mean the root of the installation rather than specifically
: > > /usr/local/pgsql.
: > >
: > > > somewhere, so they will not be removed by any
: > > > '/tmp'-clean-up-scripts.
: > > >
: > > In $PGDATA would seem as good as anywhere (maybe $PGDATA/.run or some such)
: > >
: > > /usr/local is mounted r/o on my system - $PGDATA lives elsewhere and is
: > > writable.
: >
: > $PGDATA is created 700...general users need to be able to read the
: > directory in order to connect to the socket, so we'd have to lax up
: > security in order to accomplish this...
: >
: OK, no problem, a subdirectory of $PGDATA which has world read permission
:

I think $PGDATA would be a problem. I did an initdb to my directory and
ran a postmaster on port 5440 with $PGDATA pointing to my home
directory. This postmaster never saw the main postmaster's $PGDATA
directory. All postmasters should use the same location to get
information about processes running. It wouldn't matter where, as long
as the location is flexible and easily configured.

All this raises other questions for me. I believe Goran was right about
the can of worms :)

-James

I would opt for /var/run to store the pid files and have the name set to

That would assume that postmaster runs as root, which is not
allowed...has to be in /tmp somewhere

No. Make /var/run writable by some group (e.g., group pidlog) and put
postgres (and other things like root or daemon or ..., whatever needs
to log pid files) in that group.

/var/run really is where a pid file should be. I submitted a patch
that would do this some time ago. I'll resend it if there is
interest.

Cheers,
Brook

somewhere, so they will not be removed by any
'/tmp'-clean-up-scripts.

I am convinced.
We better leave the socket in /tmp .
Any tmpwatch-scripts should not touch dot-files anyway.

<EXPLAIN>
A tmpwatch-script runs under cron and cleans out old file
from /tmp.
tmpwatch command (at least under RH5-Linux) does not touch
special-files unless -a is specified.
</EXPLAIN>

terveiset,
--
---------------------------------------------
G�ran Thyni, sysadm, JMS Bildbasen, Kiruna

I would opt for /var/run to store the pid files and have the name set to

That would assume that postmaster runs as root, which is not
allowed...has to be in /tmp somewhere

No. Make /var/run writable by some group (e.g., group pidlog) and put
postgres (and other things like root or daemon or ..., whatever needs
to log pid files) in that group.

/var/run really is where a pid file should be. I submitted a patch
that would do this some time ago. I'll resend it if there is
interest.

We can't expect the user to be able to change /var/run permissions.
Must be in pgsql/ or /tmp.

--
Bruce Momjian
maillist@candle.pha.pa.us

No. Make /var/run writable by some group (e.g., group pidlog) and put
postgres (and other things like root or daemon or ..., whatever needs
to log pid files) in that group.

We can't expect the user to be able to change /var/run permissions.
Must be in pgsql/ or /tmp.

No, "normal" users shouldn't be allowed to do so, obviously. But, are
there real systems in which a database maintainer (i.e., user
postgres) cannot cooperate with the system admin (i.e., user root) to
accomplish this? In practice, is it really envisioned that postgres
should be _so_ distinct from the system? For example, don't most
people run the postmaster from the system startup scripts, and isn't
that the same thing? How did those commands get inserted into the
startup scripts if not by root?

Cheers,
Brook

On Thu, 29 Jan 1998, Brook Milligan wrote:

No, "normal" users shouldn't be allowed to do so, obviously. But, are
there real systems in which a database maintainer (i.e., user
postgres) cannot cooperate with the system admin (i.e., user root) to
accomplish this? In practice, is it really envisioned that postgres
should be _so_ distinct from the system? For example, don't most
people run the postmaster from the system startup scripts, and isn't
that the same thing? How did those commands get inserted into the
startup scripts if not by root?

I do not feel that it is appropriate for a non-root program (which
PostgreSQL is) to require a systems administrator to make permissions
related changed to a directory for it to run, period.

In $PGDATA would seem as good as anywhere (maybe $PGDATA/.run or some such)

/usr/local is mounted r/o on my system - $PGDATA lives elsewhere and is
writable.

$PGDATA is created 700...general users need to be able to read the
directory in order to connect to the socket, so we'd have to lax up
security in order to accomplish this...

OK, no problem, a subdirectory of $PGDATA which has world read permission

You'd have to relax the 700 permissions on $PGDATA to get at
anything under that directory, even if the subdirectory under it had 777
access to it...

Duh... Wasn't thinking straight - it's been a bad week :-)
Your right, you'd have to allow read access to the directory but not
execute.

And, it also makes the assumption that you'll only ever have 1
postmaster process running on a machine, or else you are now having to set
the PGDATA environment variable depending on which database you want to
connect to...:(

Agreed, I was really just making the point that I didn't want anything
to be written to the root directory of the pgsql installation...

Andrew

----------------------------------------------------------------------------
Dr. Andrew C.R. Martin University College London
EMAIL: (Work) martin@biochem.ucl.ac.uk (Home) andrew@stagleys.demon.co.uk
URL: http://www.biochem.ucl.ac.uk/~martin
Tel: (Work) +44(0)171 419 3890 (Home) +44(0)1372 275775

I would opt for /var/run to store the pid files and have the name set to

That would assume that postmaster runs as root, which is not
allowed...has to be in /tmp somewhere

No. Make /var/run writable by some group (e.g., group pidlog) and put
postgres (and other things like root or daemon or ..., whatever needs
to log pid files) in that group.

/var/run really is where a pid file should be. I submitted a patch
that would do this some time ago. I'll resend it if there is
interest.

Cheers,
Brook

BAD idea as it means one needs to have root access to install PGSQL.
This has always been a strong point that an ordinary user could
install it and play before having to convince system managers
that it should be installed globally.

Andrew

----------------------------------------------------------------------------
Dr. Andrew C.R. Martin University College London
EMAIL: (Work) martin@biochem.ucl.ac.uk (Home) andrew@stagleys.demon.co.uk
URL: http://www.biochem.ucl.ac.uk/~martin
Tel: (Work) +44(0)171 419 3890 (Home) +44(0)1372 275775

On Thu, 29 Jan 1998, The Hermit Hacker wrote:

On Thu, 29 Jan 1998, Brook Milligan wrote:

No, "normal" users shouldn't be allowed to do so, obviously. But, are
there real systems in which a database maintainer (i.e., user
postgres) cannot cooperate with the system admin (i.e., user root) to
accomplish this? In practice, is it really envisioned that postgres
should be _so_ distinct from the system? For example, don't most
people run the postmaster from the system startup scripts, and isn't
that the same thing? How did those commands get inserted into the
startup scripts if not by root?

I do not feel that it is appropriate for a non-root program (which
PostgreSQL is) to require a systems administrator to make permissions
related changed to a directory for it to run, period.

Speaking of feelings, I'm not especially happy about allowing any old
user to trash a key file because it's located in a globally writable
directory.

Would setting the sticky bit on the permissions of the /tmp directory
help?

Marc Zuckman
marc@fallon.classyad.com

_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
_ Visit The Home and Condo MarketPlace _
_ http://www.ClassyAd.com _
_ _
_ FREE basic property listings/advertisements and searches. _
_ _
_ Try our premium, yet inexpensive services for a real _
_ selling or buying edge! _
_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

On Thu, 29 Jan 1998, Marc Howard Zuckman wrote:

Would setting the sticky bit on the permissions of the /tmp directory
help?

Ummmm...is it? *raised eyebrows* I just checked my FreeBSD boxes
and my Solaris box at the office, and sticky bit is auto-set on those...

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

No. Make /var/run writable by some group (e.g., group pidlog) and put
postgres (and other things like root or daemon or ..., whatever needs
to log pid files) in that group.

We can't expect the user to be able to change /var/run permissions.
Must be in pgsql/ or /tmp.

No, "normal" users shouldn't be allowed to do so, obviously. But, are
there real systems in which a database maintainer (i.e., user
postgres) cannot cooperate with the system admin (i.e., user root) to
accomplish this? In practice, is it really envisioned that postgres
should be _so_ distinct from the system? For example, don't most
people run the postmaster from the system startup scripts, and isn't
that the same thing? How did those commands get inserted into the
startup scripts if not by root?

Well, we have to weigh the value of moving it to /var/run vs. the
hardship for people who don't have root access. Even if only 5% don't
have root access, that is a lot of people.

--
Bruce Momjian
maillist@candle.pha.pa.us

On Thu, 29 Jan 1998, The Hermit Hacker wrote:

On Thu, 29 Jan 1998, Brook Milligan wrote:

No, "normal" users shouldn't be allowed to do so, obviously. But, are
there real systems in which a database maintainer (i.e., user
postgres) cannot cooperate with the system admin (i.e., user root) to
accomplish this? In practice, is it really envisioned that postgres
should be _so_ distinct from the system? For example, don't most
people run the postmaster from the system startup scripts, and isn't
that the same thing? How did those commands get inserted into the
startup scripts if not by root?

I do not feel that it is appropriate for a non-root program (which
PostgreSQL is) to require a systems administrator to make permissions
related changed to a directory for it to run, period.

Speaking of feelings, I'm not especially happy about allowing any old
user to trash a key file because it's located in a globally writable
directory.

Would setting the sticky bit on the permissions of the /tmp directory
help?

Most OS's or good administrators already have the sticky bit set on
/tmp, or they should. If they don't, the PostgreSQL socket file is the
least of their worries.

--
Bruce Momjian
maillist@candle.pha.pa.us

No, "normal" users shouldn't be allowed to do so, obviously. But, are
there real systems in which a database maintainer (i.e., user
postgres) cannot cooperate with the system admin (i.e., user root) to
accomplish this? In practice, is it really envisioned that postgres
should be _so_ distinct from the system? For example, don't most
people run the postmaster from the system startup scripts, and isn't
that the same thing? How did those commands get inserted into the
startup scripts if not by root?

I do not feel that it is appropriate for a non-root program (which
PostgreSQL is) to require a systems administrator to make permissions
related changed to a directory for it to run, period.

Speaking of feelings, I'm not especially happy about allowing any old
user to trash a key file because it's located in a globally writable
directory.

Correct me if I'm wrong (oh, why bother saying that? :), but aren't there two
issues going on here? And, shouldn't all points raised above (and earlier) be
considered in the solution?

One issue is that a location for sockets needs to be specified for _any_
Postgres installation. This location is not exactly the same kind of thing as
the main Postgres installation tree.

The other issue is that there _may_ be a preferred location for this location
on some, most, or all Unix systems.

In either case, the location should be specified in Makefile.global, so that I
can override it in Makefile.custom, just like I do for defining POSTGRESDIR to
allow me to work in /opt/postgres/... rather than the other possible preferred
location(s).

Perhaps the default location for an installation from source code should be
available without sysadmin intervention, which might suggest that it should be
in the postgres owner's home directory tree or in /tmp. Packaged binary
installations are likely to be installed by root into a dedicated Postgres
account.

For my installation, I'll install from source and go ahead and override the
default to put it in /var/run or somewhere like that which is more secure; the
installation instructions will tell me which is the best location to achieve
maximum security.

OK?

- Tom

On Fri, 30 Jan 1998, Thomas G. Lockhart wrote:

For my installation, I'll install from source and go ahead and override the
default to put it in /var/run or somewhere like that which is more secure; the
installation instructions will tell me which is the best location to achieve
maximum security.

OK?

This is just too intelligent of a diatribe to listen to.

Marc Zuckman
marc@fallon.classyad.com

_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
_ Visit The Home and Condo MarketPlace _
_ http://www.ClassyAd.com _
_ _
_ FREE basic property listings/advertisements and searches. _
_ _
_ Try our premium, yet inexpensive services for a real _
_ selling or buying edge! _
_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_