[HACKERS] semaphore usage "port based"?

[Marc G. Fournier]

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 at hub.org           Yahoo!: yscrappy              ICQ: 7615664