Re: Call for a hacker.... security.bsd.see_other_uids in jails only

On Fri, May 21, 2004 at 12:14:19PM +0400, Gleb Smirnoff wrote:
> On Fri, May 21, 2004 at 10:02:18AM +0200, Pawel Jakub Dawidek wrote:
> P> Implementation wouldn't be probably too hard, but I can't agree it should
> P> be committed. We need to know where jail's virtualization ends and I think
> P> it is too far. Of course it will be cool to have those sysctl on per-jail
> P> basics, as well as others from security.bsd. tree
> P> (like security.bsd.suser_enabled), but I'm not sure this is the right way
> P> to go.
> P> 
> P> Any other opinions? If someone convince me we should do it, I can do it.
> 
> A more general solution will be better, but harder to implement: make
> some sysctl branches (e.g. security.bsd) local per jail, and possibility to
> change them only from host machine.
> 
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.


Cheers,
-- 
Ruslan Ermilov
ru_at_FreeBSD.org
FreeBSD committer