
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

Mon, 26 Jan 1998 16:28:21 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
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 


Mon, 26 Jan 1998 18:31:15 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] postmaster crash and .s.pgsql file
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 


Mon, 26 Jan 1998 19:24:06 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] 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?
: 
: -- 
: 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


Mon, 26 Jan 1998 18:32:13 -0500 (EST)
James Hughes <jamesh@interpath.com>
Re: [HACKERS] postmaster crash and .s.pgsql file
Forget my complaint about local domain socket files not being removed. 
It was a socket packet bug from someone else, and it is fixed now.


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

Mon, 26 Jan 1998 23:27:30 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
lock 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?
   : 
   : -- 
   : 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);



27 Jan 1998 08:37:04 -0000
Goran Thyni <goran@bildbasen.se>
Re: [HACKERS] postmaster crash and .s.pgsql file

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.
   */


27 Jan 1998 08:39:42 -0000
Goran Thyni <goran@bildbasen.se>
Re: [HACKERS] postmaster crash and .s.pgsql file


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


Tue, 27 Jan 1998 06:14:14 -0500 (EST)
James Hughes <jamesh@interpath.com>
Re: [HACKERS] 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?
>    : 
>    : -- 
>    : 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

Tue, 27 Jan 1998 07:21:12 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] postmaster crash and .s.pgsql file

   : 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


27 Jan 1998 14:26:39 -0000
Goran Thyni <goran@bildbasen.se>
Re: [HACKERS] postmaster crash and .s.pgsql file
> 
> 
> 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

Tue, 27 Jan 1998 10:36:05 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] postmaster crash and .s.pgsql file
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 


Tue, 27 Jan 1998 23:31:14 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] postmaster crash and .s.pgsql file
> 
> 	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

Tue, 27 Jan 1998 22:37:03 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] postmaster crash and .s.pgsql file


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


Wed, 28 Jan 1998 08:24:40 -0500 (EST)
James Hughes <jamesh@interpath.com>
Re: [HACKERS] postmaster crash and .s.pgsql file
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 


Wed, 28 Jan 1998 19:58:54 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] postmaster crash and .s.pgsql file

   > 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


29 Jan 1998 08:59:27 -0000
Goran Thyni <goran@bildbasen.se>
Re: [HACKERS] postmaster crash and .s.pgsql file
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...



Thu, 29 Jan 1998 08:03:45 -0500 (EST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] postmaster crash and .s.pgsql file
   > 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

Thu, 29 Jan 1998 08:06:57 -0700 (MST)
Brook Milligan <brook@trillium.NMSU.Edu>
Re: [HACKERS] postmaster crash and .s.pgsql file
> 
>    > 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

Thu, 29 Jan 1998 11:50:48 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] postmaster crash and .s.pgsql file
> 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

Thu, 29 Jan 1998 12:10:14 -0700 (MST)
Brook Milligan <brook@trillium.NMSU.Edu>
Re: [HACKERS] postmaster crash and .s.pgsql file
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.



Thu, 29 Jan 1998 15:10:15 -0500 (EST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] postmaster crash and .s.pgsql file
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!				      _
_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_


Thu, 29 Jan 1998 15:58:21 -0500 (EST)
Marc Howard Zuckman <marc@fallon.classyad.com>
Re: [HACKERS] postmaster crash and .s.pgsql file
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 


Thu, 29 Jan 1998 17:20:53 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] postmaster crash and .s.pgsql file
> 
> > 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

Thu, 29 Jan 1998 16:23:41 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] postmaster crash and .s.pgsql file
> 
> 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

Thu, 29 Jan 1998 16:26:41 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] postmaster crash and .s.pgsql file
> > > > 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


Fri, 30 Jan 1998 02:05:39 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: [HACKERS] postmaster crash and .s.pgsql file
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!				      _
_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_


Thu, 29 Jan 1998 22:37:27 -0500 (EST)
Marc Howard Zuckman <marc@fallon.classyad.com>
Re: [HACKERS] postmaster crash and .s.pgsql file