Re: new jail(8) ignoring devfs_ruleset?
On 05/09/13 22:42, Dewayne Geraghty wrote: An ugly workaround to complete the jail closure, when relying on jail.conf, is to: jail -r $JAILNAME umount /$LOCATION_OF_JAILS/$JAILNAME/dev || true The only problem with devfs I'm aware of is it not catching the right ruleset when starting in the rc system. So does this mean you're having problems unmounting /dev? What happens when you add a "-v" to the "jail -r"? It should note that /dev is being umounted. - Jamie ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
RE: new jail(8) ignoring devfs_ruleset?
An ugly workaround to complete the jail closure, when relying on jail.conf, is to: jail -r $JAILNAME umount /$LOCATION_OF_JAILS/$JAILNAME/dev || true Regards, Dewayne. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: new jail(8) ignoring devfs_ruleset?
On 05/09/13 03:17, Jeremie Le Hen wrote: On Thu, Mar 21, 2013 at 06:46:57PM -0600, Jamie Gritton wrote: It's not fixed anywhere yet - it sometimes works in current, and sometimes doesn't. I've been meaning to patch it up, but it the problem is what I think it is, the patching up is a pretty big operation. It doesn't mean you can't use jails with devfs in 9.1, just that you can't use them with jail.conf. The old jail rc file that's all shell-based is still the official jail startup method, and that one still works. So existing systems will still work as expected, hence no errata. Shouldn't we warn the user about that in the manpage though? Well really we ought to fix it. I guess the man page could have something in the meantime, about an assumption that when you specify a devfs ruleset, that the ruleset in question must actually exist at the time. - Jamie ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: new jail(8) ignoring devfs_ruleset?
On Thu, Mar 21, 2013 at 06:46:57PM -0600, Jamie Gritton wrote: > > It's not fixed anywhere yet - it sometimes works in current, and > sometimes doesn't. I've been meaning to patch it up, but it the problem > is what I think it is, the patching up is a pretty big operation. > > It doesn't mean you can't use jails with devfs in 9.1, just that you > can't use them with jail.conf. The old jail rc file that's all > shell-based is still the official jail startup method, and that one > still works. So existing systems will still work as expected, hence no > errata. Shouldn't we warn the user about that in the manpage though? -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: new jail(8) ignoring devfs_ruleset?
On 03/21/13 18:20, Miroslav Lachman wrote:
Jamie Gritton wrote:
On 03/21/13 17:59, Miroslav Lachman wrote:
Jeremie Le Hen wrote:
On Mon, Feb 18, 2013 at 09:54:42AM +0100, Harald Schmalzbauer wrote:
schrieb Jamie Gritton am 16.02.2013 00:40 (localtime):
On 02/15/13 09:27, Harald Schmalzbauer wrote:
Hello,
like already posted, on 9.1-R, I highly appreciate the new jail(8)
and
jail.conf capabilities. Thanks for that extension!
Accidentally I saw that "devfs_ruleset" seems to be ignored.
If I list /dev/ I see all the hosts disk devices etc.
I set "devfs_ruleset = 4;" and "enforce_statfs = 1;" in jail.conf.
Inside the jail,
sysctl security.jail.devfs_ruleset returnes "1".
But like mentioned, I can access all devices...
[...]
I can confirm mentioned problem on my FreeBSD 9.1-RELEASE amd64 GENERIC
I am now testing new jail.conf possibilities and I am seeing all devices
in /dev in jail.
Even if I set all this in my jail.conf
exec.start = "/bin/sh /etc/rc";
exec.stop = "/bin/sh /etc/rc.shutdown";
exec.clean;
mount.devfs;
devfs_ruleset = 4;
allow.set_hostname = false;
path = "/vol0/jail/$name";
exec.consolelog = "/var/log/jail/$name.console";
mount.fstab = "/etc/fstab.$name";
## Jail bali
bali {
host.hostname = "bali.XXX.YY;
ip4.addr = xx.xx.xx.xx;
devfs_ruleset = 4;
}
[...]
Is it a problem in my understanding of manpage / configuration, or is it
a bug in jail command on 9.1-RELEASE?
It's a bug (deficiency) in the jail command.
Is there a workaround or is it impossible to use jails with devfs on
FreeBSD 9.1?
Shouldn't it be mentioned in 9.1 errata?
Is it fixed in stable/9?
Thank you for your reply and your great work on new jails!
It's not fixed anywhere yet - it sometimes works in current, and
sometimes doesn't. I've been meaning to patch it up, but it the problem
is what I think it is, the patching up is a pretty big operation.
It doesn't mean you can't use jails with devfs in 9.1, just that you
can't use them with jail.conf. The old jail rc file that's all
shell-based is still the official jail startup method, and that one
still works. So existing systems will still work as expected, hence no
errata.
- Jamie
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: new jail(8) ignoring devfs_ruleset?
Jamie Gritton wrote:
On 03/21/13 17:59, Miroslav Lachman wrote:
Jeremie Le Hen wrote:
On Mon, Feb 18, 2013 at 09:54:42AM +0100, Harald Schmalzbauer wrote:
schrieb Jamie Gritton am 16.02.2013 00:40 (localtime):
On 02/15/13 09:27, Harald Schmalzbauer wrote:
Hello,
like already posted, on 9.1-R, I highly appreciate the new jail(8)
and
jail.conf capabilities. Thanks for that extension!
Accidentally I saw that "devfs_ruleset" seems to be ignored.
If I list /dev/ I see all the hosts disk devices etc.
I set "devfs_ruleset = 4;" and "enforce_statfs = 1;" in jail.conf.
Inside the jail,
sysctl security.jail.devfs_ruleset returnes "1".
But like mentioned, I can access all devices...
[...]
I can confirm mentioned problem on my FreeBSD 9.1-RELEASE amd64 GENERIC
I am now testing new jail.conf possibilities and I am seeing all devices
in /dev in jail.
Even if I set all this in my jail.conf
exec.start = "/bin/sh /etc/rc";
exec.stop = "/bin/sh /etc/rc.shutdown";
exec.clean;
mount.devfs;
devfs_ruleset = 4;
allow.set_hostname = false;
path = "/vol0/jail/$name";
exec.consolelog = "/var/log/jail/$name.console";
mount.fstab = "/etc/fstab.$name";
## Jail bali
bali {
host.hostname = "bali.XXX.YY;
ip4.addr = xx.xx.xx.xx;
devfs_ruleset = 4;
}
[...]
Is it a problem in my understanding of manpage / configuration, or is it
a bug in jail command on 9.1-RELEASE?
Miroslav Lachman
It's a bug (deficiency) in the jail command.
Is there a workaround or is it impossible to use jails with devfs on
FreeBSD 9.1?
Shouldn't it be mentioned in 9.1 errata?
Is it fixed in stable/9?
Thank you for your reply and your great work on new jails!
Miroslav Lachman
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: new jail(8) ignoring devfs_ruleset?
On 03/21/13 17:59, Miroslav Lachman wrote:
Jeremie Le Hen wrote:
On Mon, Feb 18, 2013 at 09:54:42AM +0100, Harald Schmalzbauer wrote:
schrieb Jamie Gritton am 16.02.2013 00:40 (localtime):
On 02/15/13 09:27, Harald Schmalzbauer wrote:
Hello,
like already posted, on 9.1-R, I highly appreciate the new jail(8) and
jail.conf capabilities. Thanks for that extension!
Accidentally I saw that "devfs_ruleset" seems to be ignored.
If I list /dev/ I see all the hosts disk devices etc.
I set "devfs_ruleset = 4;" and "enforce_statfs = 1;" in jail.conf.
Inside the jail,
sysctl security.jail.devfs_ruleset returnes "1".
But like mentioned, I can access all devices...
Thanks for any help,
-Harry
devfs_ruleset is only used along with mount.devfs - do you also have
that set in jail.conf?
Thanks for your response.
Yes, I have mount.devfs; set.
Otherwise I wouldn't have any device inside my jail. Verified - and like
intended, right?
Another notable discrepancy: The man page tells that devfs_rulset is "4"
by default.
But when I don't set devfs_rulset in jail.conf at all, inside the jail,
'sysctl security.jail.devfs_ruleset': 0
When set, like mentioned above, it returns the corresponding value, but
it doesn't have any effect.
How gets devfs_rulset handled? Does jail(8) do the whole job? I'd like
to help finding the source, but have missed the whole new jail
evolution...
Inside my jails, I don't have a fstab, outside I have them defined and
enabled with "mount" - and noticed the non-reverted umounting.
Look at what's in /dev from you jail. There should a few pseudo
devices (see below), but no real devices:
$ ls /dev
crypto log ptmx random stdin urandom zfs
fd null pts stderr stdout zero
I can confirm mentioned problem on my FreeBSD 9.1-RELEASE amd64 GENERIC
I am now testing new jail.conf possibilities and I am seeing all devices
in /dev in jail.
Even if I set all this in my jail.conf
exec.start = "/bin/sh /etc/rc";
exec.stop = "/bin/sh /etc/rc.shutdown";
exec.clean;
mount.devfs;
devfs_ruleset = 4;
allow.set_hostname = false;
path = "/vol0/jail/$name";
exec.consolelog = "/var/log/jail/$name.console";
mount.fstab = "/etc/fstab.$name";
## Jail bali
bali {
host.hostname = "bali.XXX.YY;
ip4.addr = xx.xx.xx.xx;
devfs_ruleset = 4;
}
# jexec 4 tcsh
root@bali:/ # ls -l /dev/
total 4
crw-r--r-- 1 root wheel 0, 35 Mar 1 19:39 acpi
lrwxr-xr-x 1 root wheel 4 Mar 22 00:46 ad10 -> ada3
lrwxr-xr-x 1 root wheel 6 Mar 22 00:46 ad10s1 -> ada3s1
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad10s1a -> ada3s1a
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad10s1b -> ada3s1b
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad10s1d -> ada3s1d
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad10s1e -> ada3s1e
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad10s1f -> ada3s1f
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad10s1g -> ada3s1g
lrwxr-xr-x 1 root wheel 6 Mar 22 00:46 ad10s2 -> ada3s2
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad10s2a -> ada3s2a
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad10s2b -> ada3s2b
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad10s2d -> ada3s2d
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad10s2e -> ada3s2e
lrwxr-xr-x 1 root wheel 4 Mar 22 00:46 ad4 -> ada0
lrwxr-xr-x 1 root wheel 4 Mar 22 00:46 ad6 -> ada1
lrwxr-xr-x 1 root wheel 4 Mar 22 00:46 ad8 -> ada2
lrwxr-xr-x 1 root wheel 6 Mar 22 00:46 ad8s1 -> ada2s1
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad8s1a -> ada2s1a
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad8s1b -> ada2s1b
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad8s1d -> ada2s1d
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad8s1e -> ada2s1e
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad8s1f -> ada2s1f
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad8s1g -> ada2s1g
lrwxr-xr-x 1 root wheel 6 Mar 22 00:46 ad8s2 -> ada2s2
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad8s2a -> ada2s2a
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad8s2b -> ada2s2b
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad8s2d -> ada2s2d
lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad8s2e -> ada2s2e
crw-r- 1 root operator 0, 106 Mar 1 19:39 ada0
crw-r- 1 root operator 0, 108 Mar 1 19:39 ada1
crw-r- 1 root operator 0, 114 Mar 1 19:39 ada2
crw-r- 1 root operator 0, 120 Mar 1 19:39 ada2s1
crw-r- 1 root operator 0, 130 Mar 1 19:39 ada2s1a
crw-r- 1 root operator 0, 132 Mar 1 19:39 ada2s1b
crw-r- 1 root operator 0, 134 Mar 1 19:39 ada2s1d
crw-r- 1 root operator 0, 136 Mar 1 19:39 ada2s1e
crw-r- 1 root operator 0, 138 Mar 1 19:39 ada2s1f
crw-r- 1 root operator 0, 140 Mar 1 19:39 ada2s1g
crw-r- 1 root operator 0, 122 Mar 1 19:39 ada2s2
crw-r- 1 root operator 0, 142 Mar 1 19:39 ada2s2a
crw-r- 1 root operator 0, 144 Mar 1 19:39 ada2s2b
crw-r- 1 root operator 0, 146 Mar 1 19:39 ada2s2d
crw-r- 1 root operator 0, 148 Mar 1 19:39 ada2s2e
crw-r- 1 root operator 0, 116 Mar 1 19:39 ada3
crw-r- 1 root operator 0, 124 Mar 1 19:39 ada3s1
crw-r- 1 root operator 0, 150 Mar 1 19:39 ada3s1a
crw-r- 1 root operator 0, 154 Mar 1 19:39 ada3s1b
crw-r- 1 root operator 0, 156 Mar
Re: new jail(8) ignoring devfs_ruleset?
Jeremie Le Hen wrote:
On Mon, Feb 18, 2013 at 09:54:42AM +0100, Harald Schmalzbauer wrote:
schrieb Jamie Gritton am 16.02.2013 00:40 (localtime):
On 02/15/13 09:27, Harald Schmalzbauer wrote:
Hello,
like already posted, on 9.1-R, I highly appreciate the new jail(8) and
jail.conf capabilities. Thanks for that extension!
Accidentally I saw that "devfs_ruleset" seems to be ignored.
If I list /dev/ I see all the hosts disk devices etc.
I set "devfs_ruleset = 4;" and "enforce_statfs = 1;" in jail.conf.
Inside the jail,
sysctl security.jail.devfs_ruleset returnes "1".
But like mentioned, I can access all devices...
Thanks for any help,
-Harry
devfs_ruleset is only used along with mount.devfs - do you also have
that set in jail.conf?
Thanks for your response.
Yes, I have mount.devfs; set.
Otherwise I wouldn't have any device inside my jail. Verified - and like
intended, right?
Another notable discrepancy: The man page tells that devfs_rulset is "4"
by default.
But when I don't set devfs_rulset in jail.conf at all, inside the jail,
'sysctl security.jail.devfs_ruleset': 0
When set, like mentioned above, it returns the corresponding value, but
it doesn't have any effect.
How gets devfs_rulset handled? Does jail(8) do the whole job? I'd like
to help finding the source, but have missed the whole new jail evolution...
Inside my jails, I don't have a fstab, outside I have them defined and
enabled with "mount" - and noticed the non-reverted umounting.
Look at what's in /dev from you jail. There should a few pseudo
devices (see below), but no real devices:
$ ls /dev
crypto log ptmxrandom stdin urandom zfs
fd nullpts stderr stdout zero
I can confirm mentioned problem on my FreeBSD 9.1-RELEASE amd64 GENERIC
I am now testing new jail.conf possibilities and I am seeing all devices
in /dev in jail.
Even if I set all this in my jail.conf
exec.start = "/bin/sh /etc/rc";
exec.stop = "/bin/sh /etc/rc.shutdown";
exec.clean;
mount.devfs;
devfs_ruleset = 4;
allow.set_hostname = false;
path= "/vol0/jail/$name";
exec.consolelog = "/var/log/jail/$name.console";
mount.fstab = "/etc/fstab.$name";
## Jail bali
bali {
host.hostname = "bali.XXX.YY;
ip4.addr = xx.xx.xx.xx;
devfs_ruleset = 4;
}
# jexec 4 tcsh
root@bali:/ # ls -l /dev/
total 4
crw-r--r-- 1 root wheel 0, 35 Mar 1 19:39 acpi
lrwxr-xr-x 1 root wheel4 Mar 22 00:46 ad10 -> ada3
lrwxr-xr-x 1 root wheel6 Mar 22 00:46 ad10s1 -> ada3s1
lrwxr-xr-x 1 root wheel7 Mar 22 00:46 ad10s1a -> ada3s1a
lrwxr-xr-x 1 root wheel7 Mar 22 00:46 ad10s1b -> ada3s1b
lrwxr-xr-x 1 root wheel7 Mar 22 00:46 ad10s1d -> ada3s1d
lrwxr-xr-x 1 root wheel7 Mar 22 00:46 ad10s1e -> ada3s1e
lrwxr-xr-x 1 root wheel7 Mar 22 00:46 ad10s1f -> ada3s1f
lrwxr-xr-x 1 root wheel7 Mar 22 00:46 ad10s1g -> ada3s1g
lrwxr-xr-x 1 root wheel6 Mar 22 00:46 ad10s2 -> ada3s2
lrwxr-xr-x 1 root wheel7 Mar 22 00:46 ad10s2a -> ada3s2a
lrwxr-xr-x 1 root wheel7 Mar 22 00:46 ad10s2b -> ada3s2b
lrwxr-xr-x 1 root wheel7 Mar 22 00:46 ad10s2d -> ada3s2d
lrwxr-xr-x 1 root wheel7 Mar 22 00:46 ad10s2e -> ada3s2e
lrwxr-xr-x 1 root wheel4 Mar 22 00:46 ad4 -> ada0
lrwxr-xr-x 1 root wheel4 Mar 22 00:46 ad6 -> ada1
lrwxr-xr-x 1 root wheel4 Mar 22 00:46 ad8 -> ada2
lrwxr-xr-x 1 root wheel6 Mar 22 00:46 ad8s1 -> ada2s1
lrwxr-xr-x 1 root wheel7 Mar 22 00:46 ad8s1a -> ada2s1a
lrwxr-xr-x 1 root wheel7 Mar 22 00:46 ad8s1b -> ada2s1b
lrwxr-xr-x 1 root wheel7 Mar 22 00:46 ad8s1d -> ada2s1d
lrwxr-xr-x 1 root wheel7 Mar 22 00:46 ad8s1e -> ada2s1e
lrwxr-xr-x 1 root wheel7 Mar 22 00:46 ad8s1f -> ada2s1f
lrwxr-xr-x 1 root wheel7 Mar 22 00:46 ad8s1g -> ada2s1g
lrwxr-xr-x 1 root wheel6 Mar 22 00:46 ad8s2 -> ada2s2
lrwxr-xr-x 1 root wheel7 Mar 22 00:46 ad8s2a -> ada2s2a
lrwxr-xr-x 1 root wheel7 Mar 22 00:46 ad8s2b -> ada2s2b
lrwxr-xr-x 1 root wheel7 Mar 22 00:46 ad8s2d -> ada2s2d
lrwxr-xr-x 1 root wheel7 Mar 22 00:46 ad8s2e -> ada2s2e
crw-r- 1 root operator0, 106 Mar 1 19:39 ada0
crw-r- 1 root operator0, 108 Mar 1 19:39 ada1
crw-r- 1 root operator0, 114 Mar 1 19:39 ada2
crw-r- 1 root operator0, 120 Mar 1 19:39 ada2s1
crw-r- 1 root operator0, 130 Mar 1 19:39 ada2s1a
crw-r- 1 root operator0, 132 Mar 1 19:39 ada2s1b
crw-r- 1 root operator0, 134 Mar 1 19:39 ada2s1d
crw-r- 1 root operator0, 136 Mar 1 19:39 ada2s1e
crw-r- 1 root operator0, 138 Mar 1 19:39 ada2s1f
crw-r- 1 root operator0, 140 Mar 1 19:39 ada2s1g
crw-r- 1 root operator0, 122 Mar
Re: new jail(8) ignoring devfs_ruleset?
On Mon, Feb 18, 2013 at 09:54:42AM +0100, Harald Schmalzbauer wrote: > schrieb Jamie Gritton am 16.02.2013 00:40 (localtime): > > On 02/15/13 09:27, Harald Schmalzbauer wrote: > >> Hello, > >> > >> like already posted, on 9.1-R, I highly appreciate the new jail(8) and > >> jail.conf capabilities. Thanks for that extension! > >> > >> Accidentally I saw that "devfs_ruleset" seems to be ignored. > >> If I list /dev/ I see all the hosts disk devices etc. > >> I set "devfs_ruleset = 4;" and "enforce_statfs = 1;" in jail.conf. > >>Inside the jail, > >> sysctl security.jail.devfs_ruleset returnes "1". > >> But like mentioned, I can access all devices... > >> > >> Thanks for any help, > >> > >> -Harry > > > > devfs_ruleset is only used along with mount.devfs - do you also have > > that set in jail.conf? > > Thanks for your response. > > Yes, I have mount.devfs; set. > Otherwise I wouldn't have any device inside my jail. Verified - and like > intended, right? > Another notable discrepancy: The man page tells that devfs_rulset is "4" > by default. > But when I don't set devfs_rulset in jail.conf at all, inside the jail, > 'sysctl security.jail.devfs_ruleset': 0 > When set, like mentioned above, it returns the corresponding value, but > it doesn't have any effect. > How gets devfs_rulset handled? Does jail(8) do the whole job? I'd like > to help finding the source, but have missed the whole new jail evolution... > Inside my jails, I don't have a fstab, outside I have them defined and > enabled with "mount" - and noticed the non-reverted umounting. Look at what's in /dev from you jail. There should a few pseudo devices (see below), but no real devices: $ ls /dev crypto log ptmxrandom stdin urandom zfs fd nullpts stderr stdout zero -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: new jail(8) ignoring devfs_ruleset?
On 02/18/13 09:29, Mateusz Guzik wrote: On Mon, Feb 18, 2013 at 09:26:42AM -0700, Jamie Gritton wrote: On 02/18/13 01:54, Harald Schmalzbauer wrote: schrieb Jamie Gritton am 16.02.2013 00:40 (localtime): On 02/15/13 09:27, Harald Schmalzbauer wrote: Hello, like already posted, on 9.1-R, I highly appreciate the new jail(8) and jail.conf capabilities. Thanks for that extension! Accidentally I saw that "devfs_ruleset" seems to be ignored. If I list /dev/ I see all the hosts disk devices etc. I set "devfs_ruleset = 4;" and "enforce_statfs = 1;" in jail.conf. Inside the jail, sysctl security.jail.devfs_ruleset returnes "1". But like mentioned, I can access all devices... Thanks for any help, -Harry devfs_ruleset is only used along with mount.devfs - do you also have that set in jail.conf? Thanks for your response. Yes, I have mount.devfs; set. Otherwise I wouldn't have any device inside my jail. Verified - and like intended, right? Another notable discrepancy: The man page tells that devfs_rulset is "4" by default. But when I don't set devfs_rulset in jail.conf at all, inside the jail, 'sysctl security.jail.devfs_ruleset': 0 When set, like mentioned above, it returns the corresponding value, but it doesn't have any effect. How gets devfs_rulset handled? Does jail(8) do the whole job? I'd like to help finding the source, but have missed the whole new jail evolution... Inside my jails, I don't have a fstab, outside I have them defined and enabled with "mount" - and noticed the non-reverted umounting. I found the problem - I noticed you mentioned 9.1-R, and took a look at devfs(5). On CURRENT, there's a mount option "ruleset", that isn't there on 9. So I'll have to get around it by running devfs(8) after the mount. I'll work on a patch for that. Why not MFC support for that mount option instead? I wasn't quite right about it not being in 9.1. I was looking at my 9.0 desktop, and it's not there. But it was in fact MFCd into 9.1. So I'm back to saying as long as you use the devfs_ruleset parameter, your jailed /dev should be correct. - Jamie ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: new jail(8) ignoring devfs_ruleset?
On 02/18/13 09:29, Mateusz Guzik wrote: On Mon, Feb 18, 2013 at 09:26:42AM -0700, Jamie Gritton wrote: On 02/18/13 01:54, Harald Schmalzbauer wrote: schrieb Jamie Gritton am 16.02.2013 00:40 (localtime): On 02/15/13 09:27, Harald Schmalzbauer wrote: Hello, like already posted, on 9.1-R, I highly appreciate the new jail(8) and jail.conf capabilities. Thanks for that extension! Accidentally I saw that "devfs_ruleset" seems to be ignored. If I list /dev/ I see all the hosts disk devices etc. I set "devfs_ruleset = 4;" and "enforce_statfs = 1;" in jail.conf. Inside the jail, sysctl security.jail.devfs_ruleset returnes "1". But like mentioned, I can access all devices... Thanks for any help, -Harry devfs_ruleset is only used along with mount.devfs - do you also have that set in jail.conf? Thanks for your response. Yes, I have mount.devfs; set. Otherwise I wouldn't have any device inside my jail. Verified - and like intended, right? Another notable discrepancy: The man page tells that devfs_rulset is "4" by default. But when I don't set devfs_rulset in jail.conf at all, inside the jail, 'sysctl security.jail.devfs_ruleset': 0 When set, like mentioned above, it returns the corresponding value, but it doesn't have any effect. How gets devfs_rulset handled? Does jail(8) do the whole job? I'd like to help finding the source, but have missed the whole new jail evolution... Inside my jails, I don't have a fstab, outside I have them defined and enabled with "mount" - and noticed the non-reverted umounting. I found the problem - I noticed you mentioned 9.1-R, and took a look at devfs(5). On CURRENT, there's a mount option "ruleset", that isn't there on 9. So I'll have to get around it by running devfs(8) after the mount. I'll work on a patch for that. Why not MFC support for that mount option instead? That may be a better way around it, since either solution will require an MFC. It'd be nice to have a patch to jail(8) anyway, since just dropping in a new jail program is easier than dropping in a new kernel. I'll have to take a look at the devfs code and see if that was a reasonably small change. - Jamie ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: new jail(8) ignoring devfs_ruleset?
On Mon, Feb 18, 2013 at 09:26:42AM -0700, Jamie Gritton wrote: > On 02/18/13 01:54, Harald Schmalzbauer wrote: > > schrieb Jamie Gritton am 16.02.2013 00:40 (localtime): > >>On 02/15/13 09:27, Harald Schmalzbauer wrote: > >>> Hello, > >>> > >>>like already posted, on 9.1-R, I highly appreciate the new jail(8) and > >>>jail.conf capabilities. Thanks for that extension! > >>> > >>>Accidentally I saw that "devfs_ruleset" seems to be ignored. > >>>If I list /dev/ I see all the hosts disk devices etc. > >>>I set "devfs_ruleset = 4;" and "enforce_statfs = 1;" in jail.conf. > >>>Inside the jail, > >>>sysctl security.jail.devfs_ruleset returnes "1". > >>>But like mentioned, I can access all devices... > >>> > >>>Thanks for any help, > >>> > >>>-Harry > >> > >>devfs_ruleset is only used along with mount.devfs - do you also have > >>that set in jail.conf? > > > >Thanks for your response. > > > >Yes, I have mount.devfs; set. > >Otherwise I wouldn't have any device inside my jail. Verified - and like > >intended, right? > >Another notable discrepancy: The man page tells that devfs_rulset is "4" > >by default. > >But when I don't set devfs_rulset in jail.conf at all, inside the jail, > >'sysctl security.jail.devfs_ruleset': 0 > >When set, like mentioned above, it returns the corresponding value, but > >it doesn't have any effect. > >How gets devfs_rulset handled? Does jail(8) do the whole job? I'd like > >to help finding the source, but have missed the whole new jail evolution... > >Inside my jails, I don't have a fstab, outside I have them defined and > >enabled with "mount" - and noticed the non-reverted umounting. > > I found the problem - I noticed you mentioned 9.1-R, and took a look at > devfs(5). On CURRENT, there's a mount option "ruleset", that isn't there > on 9. > > So I'll have to get around it by running devfs(8) after the mount. I'll > work on a patch for that. > Why not MFC support for that mount option instead? -- Mateusz Guzik ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: new jail(8) ignoring devfs_ruleset?
On 02/18/13 01:54, Harald Schmalzbauer wrote: schrieb Jamie Gritton am 16.02.2013 00:40 (localtime): On 02/15/13 09:27, Harald Schmalzbauer wrote: Hello, like already posted, on 9.1-R, I highly appreciate the new jail(8) and jail.conf capabilities. Thanks for that extension! Accidentally I saw that "devfs_ruleset" seems to be ignored. If I list /dev/ I see all the hosts disk devices etc. I set "devfs_ruleset = 4;" and "enforce_statfs = 1;" in jail.conf. Inside the jail, sysctl security.jail.devfs_ruleset returnes "1". But like mentioned, I can access all devices... Thanks for any help, -Harry devfs_ruleset is only used along with mount.devfs - do you also have that set in jail.conf? Thanks for your response. Yes, I have mount.devfs; set. Otherwise I wouldn't have any device inside my jail. Verified - and like intended, right? Another notable discrepancy: The man page tells that devfs_rulset is "4" by default. But when I don't set devfs_rulset in jail.conf at all, inside the jail, 'sysctl security.jail.devfs_ruleset': 0 When set, like mentioned above, it returns the corresponding value, but it doesn't have any effect. How gets devfs_rulset handled? Does jail(8) do the whole job? I'd like to help finding the source, but have missed the whole new jail evolution... Inside my jails, I don't have a fstab, outside I have them defined and enabled with "mount" - and noticed the non-reverted umounting. I found the problem - I noticed you mentioned 9.1-R, and took a look at devfs(5). On CURRENT, there's a mount option "ruleset", that isn't there on 9. So I'll have to get around it by running devfs(8) after the mount. I'll work on a patch for that. - Jamie ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: new jail(8) ignoring devfs_ruleset?
schrieb Jamie Gritton am 16.02.2013 00:40 (localtime): > On 02/15/13 09:27, Harald Schmalzbauer wrote: >> Hello, >> >> like already posted, on 9.1-R, I highly appreciate the new jail(8) and >> jail.conf capabilities. Thanks for that extension! >> >> Accidentally I saw that "devfs_ruleset" seems to be ignored. >> If I list /dev/ I see all the hosts disk devices etc. >> I set "devfs_ruleset = 4;" and "enforce_statfs = 1;" in jail.conf. >>Inside the jail, >> sysctl security.jail.devfs_ruleset returnes "1". >> But like mentioned, I can access all devices... >> >> Thanks for any help, >> >> -Harry > > devfs_ruleset is only used along with mount.devfs - do you also have > that set in jail.conf? Thanks for your response. Yes, I have mount.devfs; set. Otherwise I wouldn't have any device inside my jail. Verified - and like intended, right? Another notable discrepancy: The man page tells that devfs_rulset is "4" by default. But when I don't set devfs_rulset in jail.conf at all, inside the jail, 'sysctl security.jail.devfs_ruleset': 0 When set, like mentioned above, it returns the corresponding value, but it doesn't have any effect. How gets devfs_rulset handled? Does jail(8) do the whole job? I'd like to help finding the source, but have missed the whole new jail evolution... Inside my jails, I don't have a fstab, outside I have them defined and enabled with "mount" - and noticed the non-reverted umounting. Thanks, -Harry signature.asc Description: OpenPGP digital signature
Re: new jail(8) ignoring devfs_ruleset?
On 02/15/13 09:27, Harald Schmalzbauer wrote: Hello, like already posted, on 9.1-R, I highly appreciate the new jail(8) and jail.conf capabilities. Thanks for that extension! Accidentally I saw that "devfs_ruleset" seems to be ignored. If I list /dev/ I see all the hosts disk devices etc. I set "devfs_ruleset = 4;" and "enforce_statfs = 1;" in jail.conf. Inside the jail, sysctl security.jail.devfs_ruleset returnes "1". But like mentioned, I can access all devices... Thanks for any help, -Harry devfs_ruleset is only used along with mount.devfs - do you also have that set in jail.conf? - Jamie ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
