On Mon, 3 Apr 2006, Robert Watson wrote:
On Mon, 3 Apr 2006, Marc G. Fournier wrote:
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 ...
The problem here is actually that two postgres instances are trying to use
the same sempahore when they are actually different postgres instances.
No, the problem here is that kill(PID, 0) reports that a PID is 'not in
use' when, in fact, it is, but in a different jail ... can someone explain
to me how 'not hiding that fact' increases information leakage, or causes
a security problem? I could see it if I could then proceed to kill that
process from a seperate jail, but I don't see what as possible ...
For all of the various sysctl's we have for reducing "security due to
jails", I think something like that for this instance would be more benign
then any of the rest of them :(
That is all I'm advocatin / asking for ... some way of reverting kill(PID,
0) back to the old, FreeBSD 4.x behaviour, where this works beautifully :(
At least until someone does get around to 'virtualization of SysV IPC' :(
Does PGSQL have a way to specify the semaphore ID to use?
Yes, changing the port # that the server responds on ...
----
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]"
