DragonFlyBSD

On Sun, Mar 19, 2006 at 10:16:29PM +0100, Michal Belczyk wrote:

the attached patches make it a bit easier to setup jails (no fake /etc/fstab,
no additional network_interfaces="" in jails' /etc/rc.conf, etc) since some
services are not supposed to run inside jail.

I never liked the nojail keyword. Anyway, I don't like the new sysctl
either, since it is redundant. Try "kill 0 1" :)

Joerg

joerg@britannica.bec.de wrote:

the attached patches make it a bit easier to setup jails (no fake /etc/fstab,
no additional network_interfaces="" in jails' /etc/rc.conf, etc) since some
services are not supposed to run inside jail.

I never liked the nojail keyword. Anyway, I don't like the new sysctl
either, since it is redundant. Try "kill 0 1" :)

I actually quite like the patch. And having a sysctl telling explicitly
if running in a jail or not seems a very sane idea. What does FreeBSD do?

cheers
simon

Hi,

Exactly that sysctl exists on FreeBSD as well. And I also consider an
explicit sysctl way better than some non-obvious[*] method to figure out
the same.

Regards,
--
Andreas

[*] The man page of kill doesn't mention "0" as a way to check if a
process is jailed, and neither jail(2) nor jail(8) talk about it. And I
don't think a user new to jails imagines that trying and failing to send
a non-existing (cf. sys/signal.h, signal(3)) to init will tell him
whether he is jailed or not. But I may be overlooking something obvious,
of course :)

On Mon, Mar 20, 2006 at 12:29:47AM +0100, Andreas Kohn wrote:

[*] The man page of kill doesn't mention "0" as a way to check if a
process is jailed, and neither jail(2) nor jail(8) talk about it.

"0" is a valid signal and the standard check to see if a process exists.
Which process is known to run in the base system and can't exist in a
jail therefore?

Joerg

On 20.03.2006, at 00:29, Andreas Kohn wrote:

[*] The man page of kill doesn't mention "0" as a way to check if a
process is jailed, and neither jail(2) nor jail(8) talk about it. And I
don't think a user new to jails imagines that trying and failing to
send
a non-existing (cf. sys/signal.h, signal(3)) to init will tell him
whether he is jailed or not. But I may be overlooking something
obvious,
of course :)

you'll get a ESRCH if you're in a jail, i guess. or a EPERM?
whatever, the sysctl is the way to go, IMO.

cheers
simon

Moin,

To be fair, the man pages of FreeBSD's jail(8) utility or jail(2) also
do not mention the security.jail.jailed sysctl. [*]

I do however consider it way more obvious to check an explicit sysctl,
or try to find one by looking at the related controls, than using kill,
ps, or trying to bind a socket to 0.0.0.0 or whatever.

On Mon, 2006-03-20 at 00:51 +0100, joerg@britannica.bec.de wrote:

"0" is a valid signal and the standard check to see if a process exists.
Which process is known to run in the base system and can't exist in a
jail therefore?

On Mon, 2006-03-20 at 01:14 +0100, Simon 'corecode' Schubert wrote:

you'll get a ESRCH if you're in a jail, i guess. or a EPERM?

I guess. My argument was not that there are no other methods, but that a
sysctl is more obvious than those methods. Compare the commit message
when the sysctl was added to FreeBSD:

----
date: 2004/02/19 14:29:14; author: pjd; state: Exp; lines: +13 0
Added sysctl security.jail.jailed.
It returns 1 is process is inside of jail and 0 if it is not.
Information if we are in jail or not is not a secret, there is plenty
of ways to discover it. Many people are using own hack to check this
and this will be a legal way from now on.
---

Regards,
Andreas

[*] Which of course can be changed, thanks for the idea :)
http://www.freebsd.org/cgi/query-pr.cgi?pr=94711

On Sun, Mar 19, 2006 at 10:52:08PM +0100, joerg@britannica.bec.de wrote:

On Sun, Mar 19, 2006 at 10:16:29PM +0100, Michal Belczyk wrote:

the attached patches make it a bit easier to setup jails (no fake /etc/fstab,
no additional network_interfaces="" in jails' /etc/rc.conf, etc) since some
services are not supposed to run inside jail.

I never liked the nojail keyword. Anyway, I don't like the new sysctl
either, since it is redundant. Try "kill 0 1" :)

OK, so suggest another keyword to use, change the check in /etc/rc and ignore
the kernel patch I sent. Where's the problem?

IMHO this should be commited (at least the sysctl). Any other opinion?

Cheers,
Alex Hornung

This is related to the GSOC project idea I put forth. Apparently Enjolras is also looking at it, perhaps in the context of GSoC or even separately.