Re: We should Axe /contrib/start-scripts

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: "Josh Berkus" <josh(at)agliodbs(dot)com>, "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, "Chander Ganesan" <chander(at)otg-nc(dot)com>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: We should Axe /contrib/start-scripts
Date: 2009-08-25 20:41:00
Message-ID: 2325.1251232860@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> You're thinking that pg_ctl would capture it's parent PID and pass it
> to the postmaster one way or the other? That seems like it covers the
> specific issue you were referencing up-thread. It has been bubbling
> around in my head that we have other processes which run under the
> same user ID for such things as vacuum and purge scripts, as well as
> rsync of backup files. These would still create some risk of a false
> match, right? Just a much smaller risk?

Only if they are running at times when your postmaster(s) aren't ...
realistically, unless you launch them from initscripts that start before
your postmasters launch, I don't think there's going to be a problem.
Still, just from a security point of view, it might be better if those
don't run as the postgres operating-system user. Not sure if that's
workable for rsync (since it has to be able to read the postgres files)
but stuff like vacuum scripts could surely be run from a different
userid.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2009-08-25 20:41:41 Re: We should Axe /contrib/start-scripts
Previous Message Alvaro Herrera 2009-08-25 20:39:50 Re: pg_hba.conf: samehost and samenet