On Fri, May 21, 2004 at 12:02:17PM +0300, Ruslan Ermilov wrote: +> I like the idea of per-jail sysctl MIB trees, e.g.: +> +> jail.<JID>.security.bsd +> +> When jail gets created, the generic sysctl code would traverse +> the primary sysctl tree (excluding the jail. subtree), and copy +> and attach those that have some jail-related flag to the +> jail.<JID>. branch. +> +> Inside the jail, jail.<JID>.security.bsd branch would map to +> just security.bsd. +> +> The generic sysctl code, when it detects it's run within a +> jail, will find a sysctl node "foo.bar", and if it has a +> jail-clone flag set, will remap a query to jail.<JID>.foo.bar. +> +> Whether it's allowed to change a particular sysctl inside +> a jail is another matter. There are two main issues with our current sysctls implementation: 1. We cannot hide sysctls/sysctl-trees. 2. We're operating in most cases on integers. We can work on 1, but we can't hack 2 easly, we have to transform sysctls, that have to be treated on per-jail basics from SYSCTL_INT to SYSCTL_PROC and if so, I'm not sure what for do we need security.jail.<JID> trees then. We can implement them in the same way security.jail.jailed is impelemented (it shows different value outside a jail and different inside) and if we want to change it: # jexec <JID> /sbin/sysctl <some_sysctl>=<some_value> Of course, there could be no /sbin/sysctl utility inside a jail, but I'll still suggest to add '-j' option to sysctl command to work just like 'killall -j' (i.e. jail_attach(<JID>); sysctl();). -- Pawel Jakub Dawidek http://www.FreeBSD.org pjd_at_FreeBSD.org http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am!
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:54 UTC