Re: Effective rule sets in a jail?
Ultima wrote on 07/07/2016 06:04: Not so. The top variable, devfs_ruleset = 4 is being set as the default for all jails. The devfs_ruleset = 5 inside the brackets is changing the default value. How to check what ruleset is mounted? That is a great question. I'm not sure of an easy way to check other than verifying the /dev directory inside the jail. There is no way to set more than one devfs rule to jail AFAIK. You can see the rule number in output of jls -s or jls -n. Miroslav Lachman ___ freebsd-jail@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-jail To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"
Re: Effective rule sets in a jail?
On 07/07/2016 07:53, Miroslav Lachman wrote: Ultima wrote on 07/07/2016 06:04: Not so. The top variable, devfs_ruleset = 4 is being set as the default for all jails. The devfs_ruleset = 5 inside the brackets is changing the default value. How to check what ruleset is mounted? That is a great question. I'm not sure of an easy way to check other than verifying the /dev directory inside the jail. There is no way to set more than one devfs rule to jail AFAIK. You can see the rule number in output of jls -s or jls -n. Miroslav Lachman I was referring to this clause in the man document: Descendant jails inherit the parent jail's devfs ruleset enforcement. I thought that the outside rule is combined with the inside rule in the jail definition. But thanks for the hint about jls -s, it does shows the (single) active rule set (however without referring to the specific rules defined in devfs.rules or a combination of it). Grzegorz ___ freebsd-jail@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-jail To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"
Re: Effective rule sets in a jail?
Grzegorz Junka wrote on 07/07/2016 10:41: I was referring to this clause in the man document: Descendant jails inherit the parent jail's devfs ruleset enforcement. This is true for hierarchical "nested" jails = jail inside jail. And inheriting doesn't mean merging. You can't allow devices in descendant jail which are not allowed on parent. I thought that the outside rule is combined with the inside rule in the jail definition. But thanks for the hint about jls -s, it does shows the (single) active rule set (however without referring to the specific rules defined in devfs.rules or a combination of it). You are mixing nested jails context with jail.conf context where "outside" definitions are the defaults for all jails which are not overriding those values with own values. Miroslav Lachman ___ freebsd-jail@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-jail To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"
Re: Effective rule sets in a jail?
On 07/07/2016 09:03, Miroslav Lachman wrote: Grzegorz Junka wrote on 07/07/2016 10:41: I was referring to this clause in the man document: Descendant jails inherit the parent jail's devfs ruleset enforcement. This is true for hierarchical "nested" jails = jail inside jail. And inheriting doesn't mean merging. You can't allow devices in descendant jail which are not allowed on parent. I thought that the outside rule is combined with the inside rule in the jail definition. But thanks for the hint about jls -s, it does shows the (single) active rule set (however without referring to the specific rules defined in devfs.rules or a combination of it). You are mixing nested jails context with jail.conf context where "outside" definitions are the defaults for all jails which are not overriding those values with own values. Miroslav Lachman OK, I am just an user, not very familiar with the terminology. For me (as a programmer) inheriting means overriding, so merging the more specific to the less specific declarations. Does it mean that the "inheriting" works in nested declarations but doesn't take into account the default value? In other words, the default is just default unless it re-defined in a jail declaration. If that's the case then wouldn't be more clear to name the "outside" default declaration as default, e.g. "default_devfs_ruleset"? Then it would be more difficult to confuse the default with the one that can be inherited. Grzegorz ___ freebsd-jail@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-jail To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"
Re: Effective rule sets in a jail?
Grzegorz Junka wrote on 07/07/2016 11:42:
OK, I am just an user, not very familiar with the terminology. For me
(as a programmer) inheriting means overriding, so merging the more
specific to the less specific declarations.
Does it mean that the "inheriting" works in nested declarations but
doesn't take into account the default value? In other words, the default
is just default unless it re-defined in a jail declaration. If that's
the case then wouldn't be more clear to name the "outside" default
declaration as default, e.g. "default_devfs_ruleset"? Then it would be
more difficult to confuse the default with the one that can be inherited.
I think it is simple in current form. (And I am not sys developer, I was
web application programmer before I became sysadmin)
I started with jails long time before jail2 with jail.conf. Current
jail.conf is s simpler in comparision with rc.conf style variables.
Naming each default variable with different name will be harder to code,
harder to write in jail.conf, harder to document in manpages.
Almost all programming languages works the same in this context - later
variable definition wins.
So you can easily define all variables needed to run jails and then set
just those specific to one jail - IPs and hostname:
## Typical static defaults:
## Use the rc scripts to start and stop jails. Mount jail's /dev.
exec.start = "/bin/sh /etc/rc";
exec.stop = "/bin/sh /etc/rc.shutdown";
exec.clean;
exec.system_user = "root";
exec.jail_user = "root";
mount.devfs;
devfs_ruleset = 4;
enforce_statfs = 1;
#allow.set_hostname = false;
#allow.mount;
allow.set_hostname = 0;
allow.sysvipc = 0;
allow.raw_sockets = 0;
## Dynamic wildcard parameter:
path= "/vol1/jail/$name";
exec.consolelog = "/var/log/jail/$name.console";
mount.fstab = "/etc/fstab.$name";
## Jail myjail0
myjail0 {
host.hostname = "myjail0.example.conf";
ip4.addr = 10.20.30.40;
}
## Jail myjail1
myjail1 {
host.hostname = "myjail1.example.conf";
ip4.addr = 10.20.30.41;
}
devfs_ruleset is the same as the other variables - you can't (and I hope
nobody expect) to merge global default value of e.g. exec.system_user or
allow.sysvipc with variables defined in specific jail context. Those
variables can have only one value (bool, or string, or number; not an
array). It is the same for devfs_rules. Can't have more than one numeric
value, can't combine two together.
I think you will be familiar with this very soon.
Miroslav Lachman
___
freebsd-jail@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"
Re: Effective rule sets in a jail?
On 07/07/2016 10:06, Miroslav Lachman wrote:
Grzegorz Junka wrote on 07/07/2016 11:42:
OK, I am just an user, not very familiar with the terminology. For me
(as a programmer) inheriting means overriding, so merging the more
specific to the less specific declarations.
Does it mean that the "inheriting" works in nested declarations but
doesn't take into account the default value? In other words, the default
is just default unless it re-defined in a jail declaration. If that's
the case then wouldn't be more clear to name the "outside" default
declaration as default, e.g. "default_devfs_ruleset"? Then it would be
more difficult to confuse the default with the one that can be
inherited.
I think it is simple in current form. (And I am not sys developer, I
was web application programmer before I became sysadmin)
I started with jails long time before jail2 with jail.conf. Current
jail.conf is s simpler in comparision with rc.conf style variables.
Naming each default variable with different name will be harder to
code, harder to write in jail.conf, harder to document in manpages.
Almost all programming languages works the same in this context -
later variable definition wins.
So you can easily define all variables needed to run jails and then
set just those specific to one jail - IPs and hostname:
## Typical static defaults:
## Use the rc scripts to start and stop jails. Mount jail's /dev.
exec.start = "/bin/sh /etc/rc";
exec.stop = "/bin/sh /etc/rc.shutdown";
exec.clean;
exec.system_user = "root";
exec.jail_user = "root";
mount.devfs;
devfs_ruleset = 4;
enforce_statfs = 1;
#allow.set_hostname = false;
#allow.mount;
allow.set_hostname = 0;
allow.sysvipc = 0;
allow.raw_sockets = 0;
## Dynamic wildcard parameter:
path= "/vol1/jail/$name";
exec.consolelog = "/var/log/jail/$name.console";
mount.fstab = "/etc/fstab.$name";
## Jail myjail0
myjail0 {
host.hostname = "myjail0.example.conf";
ip4.addr = 10.20.30.40;
}
## Jail myjail1
myjail1 {
host.hostname = "myjail1.example.conf";
ip4.addr = 10.20.30.41;
}
devfs_ruleset is the same as the other variables - you can't (and I
hope nobody expect) to merge global default value of e.g.
exec.system_user or allow.sysvipc with variables defined in specific
jail context. Those variables can have only one value (bool, or
string, or number; not an array). It is the same for devfs_rules.
Can't have more than one numeric value, can't combine two together.
I think you will be familiar with this very soon.
Miroslav Lachman
OK, so my confusion steams from the fact that the devfs rules are
defined somewhere else and the jail.conf is simply taking into account
the rule number, not its content. In that context it indeed makes sense.
It could be simply a matter of adding a clarification that each jail can
have only one devfs ruleset assigned to it (which then would be
calculated according to the standard rules defined in jail.conf), for
example:
Descendant jails inherit the parent jail's devfs ruleset. Devfs rules
enforced in the jail are defined by the single calculated ruleset.
What do you think?
Grzegorz
___
freebsd-jail@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"
Re: Effective rule sets in a jail?
On Thu, 7 Jul 2016 11:17:41 + Grzegorz Junka wrote: > > Descendant jails inherit the parent jail's devfs ruleset. Devfs rules > enforced in the jail are defined by the single calculated ruleset. > > What do you think? > IMHO, regarding jails, better mental model would be like this: - any single jail can have one and only one devfs ruleset number assigned - however, different standalone jails can have different devfs ruleset number assigned - nested jails inherit ruleset number from their parent jail Regarding rulesets "inheritance"/"merging" you are probably looking into the wrong place. devfs ruleset system is completely orthogonal to jails, as it is used for other things as well. You can "merge" devfs rulesets in devfs /etc/devfs.rules. Look into /etc/defaults/devfs.rules how initial rulesets are built. First everything is hidden by ruleset 1 aka "devfsrules_hide_all". This is "by default deny" policy, which should, according to me, used whenever one can. Then, new rulesets are created by unhiding various groups of devices. Like for example you have minimal sub-ruleset 2 aka "devfsrules_unhide_basic". That one is required to get minimal working /dev. Otherwise most programs break. Finally ruleset 4 aka "devfsrules_jail" is built, which can be used by jails. I personally "classify" jail types into groups. Let's call such group a jail "class" (for the purpose of classification). Thus to get what you want, you should create custom ruleset per jail "class" and assign it to your jails based on their "class". [devfsrules_jail_class_no_zfs=16] add include $devfsrules_hide_all add include $devfsrules_unhide_basic add include $devfsrules_unhide_login Class might be not good word for this, as it is quite "loaded" by now, but I am using it that way. Some jails might end up so special, they require completely fine tuned ruleset. Those cannot be completely "classified" at all like this for example: [devfsrules_jail_proxy=333] add include $devfsrules_hide_all add include $devfsrules_unhide_basic add include $devfsrules_unhide_login add include $devfsrules_unhide_jail_proxy_tuns "devfsrules_unhide_jail_proxy_tuns" sub-rule in this case unhides several tun interfaces used solely by this jail only. devfs.conf files are "parsed" by /etc/rc.d/devfs rc script which is run quite early after boot. If you look at it you will see it is using /etc/rc.subr devfs_* subroutines of rc.d framework which invoke /sbin/devfs helper program. Theoretically if /etc/rc.d/devfs and /etc/rc.subr are not enough for you, you could write helper script to invoke /sbin/devfs to setup most convoluted rule ids directly by hand. eto ___ freebsd-jail@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-jail To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"
Re: Effective rule sets in a jail?
On 07/07/2016 13:31, Martin "eto" Misuth wrote: IMHO, regarding jails, better mental model would be like this: - any single jail can have one and only one devfs ruleset number assigned - however, different standalone jails can have different devfs ruleset number assigned - nested jails inherit ruleset number from their parent jail Regarding rulesets "inheritance"/"merging" you are probably looking into the wrong place. devfs ruleset system is completely orthogonal to jails, as it is used for other things as well. You can "merge" devfs rulesets in devfs /etc/devfs.rules. Look into /etc/defaults/devfs.rules how initial rulesets are built. First everything is hidden by ruleset 1 aka "devfsrules_hide_all". This is "by default deny" policy, which should, according to me, used whenever one can. Then, new rulesets are created by unhiding various groups of devices. Like for example you have minimal sub-ruleset 2 aka "devfsrules_unhide_basic". That one is required to get minimal working /dev. Otherwise most programs break. Finally ruleset 4 aka "devfsrules_jail" is built, which can be used by jails. I personally "classify" jail types into groups. Let's call such group a jail "class" (for the purpose of classification). Thus to get what you want, you should create custom ruleset per jail "class" and assign it to your jails based on their "class". [devfsrules_jail_class_no_zfs=16] add include $devfsrules_hide_all add include $devfsrules_unhide_basic add include $devfsrules_unhide_login Class might be not good word for this, as it is quite "loaded" by now, but I am using it that way. Some jails might end up so special, they require completely fine tuned ruleset. Those cannot be completely "classified" at all like this for example: [devfsrules_jail_proxy=333] add include $devfsrules_hide_all add include $devfsrules_unhide_basic add include $devfsrules_unhide_login add include $devfsrules_unhide_jail_proxy_tuns "devfsrules_unhide_jail_proxy_tuns" sub-rule in this case unhides several tun interfaces used solely by this jail only. devfs.conf files are "parsed" by /etc/rc.d/devfs rc script which is run quite early after boot. If you look at it you will see it is using /etc/rc.subr devfs_* subroutines of rc.d framework which invoke /sbin/devfs helper program. Theoretically if /etc/rc.d/devfs and /etc/rc.subr are not enough for you, you could write helper script to invoke /sbin/devfs to setup most convoluted rule ids directly by hand. eto ___ freebsd-jail@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-jail To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org" That's great! Thanks for the comprehensive explanation, I wish it was in the man already so I wouldn't need to enquiry additionally here. It makes sense, as I mentioned in my previous email, I got confused and messed jail inheritance with the inheritance of devfs rule sets, they are orthogonal as you stated. I amended my rules to include the basic ones from rule 4 to the more specific one for one particular jail and it works. Thanks again! Grzegorz ___ freebsd-jail@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-jail To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"
