[HACKERS] semaphore usage "port based"?

[Daniel Eischen]

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