Skip site navigation (1)Skip section navigation (2)
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>