On Mon, 3 Apr 2006, Daniel Eischen wrote:
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.
I don't really see what the problem is. ESRCH seems perfectly
reasonable for trying to kill (even sig 0) a process from a
different jail. If you're in a jail, then you shouldn't have
knowledge of processes from other jails.
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 ...
----
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]"
