Closed igalic closed 5 years ago
to quote the jail(8) man page:
devfs_ruleset
The number of the devfs ruleset that is enforced for mounting devfs in this jail. A value of zero (default) means no ruleset is enforced. Descendant jails inherit the parent jail's devfs ruleset enforcement. Mounting devfs inside a jail is possible only if the
allow.mount
andallow.mount.devfs
permissions are effective andenforce_statfs
is set to a value lower than 2. Devfs rules and rulesets cannot be viewed or modified from inside a jail.NOTE: It is important that only appropriate device nodes in devfs be exposed to a jail; access to disk devices in the jail may permit processes in the jail to bypass the jail sandboxing by modifying files outside of the jail. See devfs(8) for information on how to use devfs rules to limit access to entries in the per-jail devfs. A simple devfs ruleset for jails is available as ruleset
#4
in /etc/defaults/devfs.rules.
and
enforce_statfs
This determines what information processes in a jail are able to get about mount points. It affects the behaviour of the following syscalls: statfs(2), fstatfs(2), getfsstat(2), and fhstatfs(2) (as well as similar compatibility syscalls). When set to 0, all mount points are available without any restrictions. When set to 1, only mount points below the jail's chroot directory are visible. In addition to that, the path to the jail's chroot directory is removed from the front of their pathnames. When set to 2 (default), above syscalls can operate only on a mount-point where the jail's chroot directory is located.
results from further investigation:
this function
is never called
funnily enough, that function was only introduced in https://github.com/bsdci/libioc/pull/727 — which is believed to be the cause of this issue.
fixed in #734
since https://github.com/bsdci/libioc/pull/727 DHCP no longer works: