On Mon, 3 Apr 2006, Daniel Eischen wrote:
On Tue, 4 Apr 2006, Peter Jeremy wrote:
On Mon, 2006-Apr-03 08:19:00 -0400, Daniel Eischen wrote:
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.
I agree in general. The problem here is that SysV IPC isn't
jail-aware - there's a single SysV IPC address space across the
physical system. This confuses (eg) postgres because it can
see the SHM for a postgres instance in another jail but kill(2)
claims that the process associated with that SHM doesn't exist.
There appear to be two solutions:
1) Add a sysctl to change cr_cansignal() and/or prison_check() to
make processes visible between jails.
2) Change SysV IPC to be jail-aware.
The former is trivial - but has a number of security implications.
The latter is much harder, there is apparently a RELENG_4 patch in
kern/48471 but it's not clear how much work would be necessary to
being it up to scratch.
Or:
3) Run postgres in such a way that it doesn't look for
remnant IPC information from other instances (use a
per-jail-specific port #?).
Postgres has no business cleaning up after different jailed
instances of itself, which it wouldn't do if IPC's were
per-jail. So since IPC's don't currently work that way,
account for it by the way you run postgres.
This falls under "well,we broke kill() so that it now reports a PID is not
in use even though it is, so its has to be the application that fixes it"
... and you *still* haven't shown *why* kill() reporting a PID is in use,
even if its not in the current jail, is such a security threat ...
----
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]"
