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.
'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?
----
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]"
