Re: We should Axe /contrib/start-scripts

On Thu, Aug 27, 2009 at 12:32 AM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Attached is a simple patch that uses the environment-variable approach.
> This is a whole lot more self-contained than what would be needed to
> pass the PID as an explicit switch, so I'm inclined to do it this way.
> You could argue that a bad guy could confuse matters by intentionally
> passing an existing postmaster's PID in this variable --- but someone
> with the ability to launch the postmaster can probably also remove an
> existing lockfile, so I don't think there's a credible security risk.
>
> Any objections?

So with this change you would have the startup script not remove the
lock file? Postgres would refuse to start up if there was another
process with the same uid running as long as it wasn't pg_ctl or the
parent of pg_ctl?

This could still fail if the startup script runs some other commands
with & to background them and those commands happen to land with the
pid of postgres? Or the startup script runs pg_ctl within a ( )
subshell?

Or are you suggesting making this change but then still recommending
the startup script you have now. So this would just be to make the
problem less severe for people who use pg_ctl without being aware of
the problem?

--
greg
http://mit.edu/~gsstark/resume.pdf