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: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
