[HACKERS] semaphore usage "port based"?

Marc G. Fournier scrappy at postgresql.org
Mon Apr 3 04:24:09 UTC 2006


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?

On Mon, 3 Apr 2006, Andrew Thompson wrote:

> On Sun, Apr 02, 2006 at 11:41:01PM -0400, Kris Kennaway wrote:
>> On Mon, Apr 03, 2006 at 12:30:58AM -0300, Marc G. Fournier wrote:
>>> 'k, but how do I fix kill so that it has the proper behaviour if SysV is
>>> enabled?
>>
>> Check the source, perhaps there's already a way.  If not, talk to
>> whoever made the change.
>>
>>> Maybe a mount option for procfs that allows for pre-5.x
>>> behaviour?
>>
>> procfs has nothing to do with this though.
>>
>>> I'm not the first one to point out that this is a problem, just
>>> the first to follow it through to the cause ;(  And I believe there is
>>> more then just PostgreSQL that is affected by shared memory (ie. apache2
>>> needs SysV IPC enabled, so anyone doing that in a jail has it enabled
>>> also) ...
>>
>> Also note that SysV IPC is not the problem here, it's the change in
>> the behaviour of kill() that is causing postgresql to become confused.
>> That's what you should investigate.
>
> The ESRCH error is being returned from prison_check(), that would be a
> good starting place.
>
>
> Andrew
> _______________________________________________
> freebsd-stable at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
>
>

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


More information about the freebsd-stable mailing list