[HACKERS] semaphore usage "port based"?

[Marc G. Fournier]

On Mon, 3 Apr 2006, Andrew Thompson wrote:

> On Mon, Apr 03, 2006 at 01:57:17AM -0300, Marc G. Fournier wrote:
>> On Mon, 3 Apr 2006, Andrew Thompson wrote:
>>
>>> On Mon, Apr 03, 2006 at 01:23:59AM -0300, Marc G. Fournier wrote:
>>>>
>>>> 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.
>>
>> 'k, first question is 'what information leak' are we trying to protect
>> from?  to 'make postgres a bit happier', all that needs to be fixed, from
>> what I can tell, is that cr_cansignal() needs to work for signal 0, but no
>> other signals ... what risk of information leak does that create?
>
> By returning EPERM instead then the kernel is acknowledging that the pid
> exists. In theory jails shouldnt be able to find out info about other
> jails or the base system, postgres just relies on this.

Ah, okay, I understand what you mean ... and yes, this would be perfect 
...

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