[HACKERS] semaphore usage "port based"?

[Marc G. Fournier]

On Mon, 3 Apr 2006, Daniel Eischen wrote:

> On Mon, 3 Apr 2006, Andrew Thompson wrote:
>
>> On Mon, Apr 03, 2006 at 01:23:59AM -0300, Marc G. Fournier wrote:
>>>
>>> taking it off of pgsql-hackers, so that we don't annoy them unnecessarily
>>> ...
>>>
>>> 'k, looking at the code, not that most of it doesn't go over my head ...
>>> but ...
>>>
>>> in kern/kern_jail.c, I can see the prison_check() call ... wouldn't one
>>> want to make the change a bit further up?  say in kern_prot.c?  wouldn't
>>> you want to change just cr_cansignal() to allow *just* for 'case 0', when
>>> someone is just checking to see if a process is already running?  I
>>> wouldn't want to be able to SIGKILL the process from a different jail,
>>> mind you ... maybe move the check for SIG0 to just before the
>>> prison_check, since, unless I'm missing something, other then determining
>>> that a process is, in fact, running, SIG0 is a benign signal?
>>>
>>
>> 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 ...


----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy at hub.org           Yahoo!: yscrappy              ICQ: 7615664