Date: Mon, 3 Apr 2006 14:55:10 -0300 (ADT) From: "Marc G. Fournier" <scrappy@postgresql.org> To: Robert Watson <rwatson@FreeBSD.org> Cc: Daniel Eischen <deischen@freebsd.org>, "Marc G. Fournier" <scrappy@postgresql.org>, freebsd-stable@freebsd.org, Andrew Thompson <thompsa@freebsd.org>, Kris Kennaway <kris@obsecurity.org> Subject: Re: [HACKERS] semaphore usage "port based"? Message-ID: <20060403144916.J947@ganymede.hub.org> In-Reply-To: <20060403182504.S76562@fledge.watson.org> References: <Pine.GSO.4.43.0604030817090.21105-100000@sea.ntplx.net> <20060403140902.C947@ganymede.hub.org> <20060403182504.S76562@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 3 Apr 2006, Robert Watson wrote: > > On Mon, 3 Apr 2006, Marc G. Fournier wrote: > >> The problem is that PostgreSQL uses kill(PID, 0) to determine whether or >> not another process is running when it tries to allocate a semaphore ... >> >> for instance, when it starts up, it tries to semget(54320001); ... if that >> fails, based on the PID that is attached to that semaphore, it tries to do >> a kill(PID,0) ... if that fails, it then *takes over* that semaphore ... >> under 4.x, kill(PID,0) *would* return that a process is running, even if it >> was in another jail, altho the jail issuing the kill can't see that >> process, so postgresql would go on to 54320002, and test that ... under >> FreeBSD 6.x, kill(PID, 0) reports "not in use", so PostgreSQL stomps on >> that semaphore ... Robert brought up a good point, about recycled PIDs, but >> Tom Lane's response to that about the fact that we don't care if the >> process that is running is the one *actually* holding the semaphore, we'd >> rather err on the side of caution and just move on ... but we need to >> *know* that we need to move on ... >> >> We don't need any more information about that process ID then that it is >> "currently in use" ... nd I think that is where Andrew was coming from with >> issueing EPERM rather then ESRCH ... > > The problem here is actually that two postgres instances are trying to use > the same sempahore when they are actually different postgres instances. No, the problem here is that kill(PID, 0) reports that a PID is 'not in use' when, in fact, it is, but in a different jail ... can someone explain to me how 'not hiding that fact' increases information leakage, or causes a security problem? I could see it if I could then proceed to kill that process from a seperate jail, but I don't see what as possible ... For all of the various sysctl's we have for reducing "security due to jails", I think something like that for this instance would be more benign then any of the rest of them :( That is all I'm advocatin / asking for ... some way of reverting kill(PID, 0) back to the old, FreeBSD 4.x behaviour, where this works beautifully :( At least until someone does get around to 'virtualization of SysV IPC' :( > Does PGSQL have a way to specify the semaphore ID to use? Yes, changing the port # that the server responds on ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060403144916.J947>