Date: Mon, 3 Apr 2006 13:20:05 -0400 (EDT) From: Daniel Eischen <deischen@freebsd.org> To: "Marc G. Fournier" <scrappy@postgresql.org> Cc: freebsd-stable@freebsd.org, Andrew Thompson <thompsa@freebsd.org>, Kris Kennaway <kris@obsecurity.org> Subject: Re: [HACKERS] semaphore usage "port based"? Message-ID: <Pine.GSO.4.43.0604031317530.22397-100000@sea.ntplx.net> In-Reply-To: <20060403140902.C947@ganymede.hub.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 3 Apr 2006, Marc G. Fournier wrote: > On Mon, 3 Apr 2006, Daniel Eischen wrote: > > >> I think the suggestion was to make this EPERM rather than ESRCH to make > >> postgres a bit happier, not remove the check entirely. Im not familiar > >> with that part of the kernel at all, so I cant say what the consequences > >> will be apart from the obvious information leak. > > > > I don't really see what the problem is. ESRCH seems perfectly > > reasonable for trying to kill (even sig 0) a process from a > > different jail. If you're in a jail, then you shouldn't have > > knowledge of processes from other jails. > > 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 ... I still think ESRCH is correct. The problem isn't that kill isn't seeing other processes; it's that semaphores can be contaminated by different jails. -- DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.43.0604031317530.22397-100000>