automatic garbage collection of stuff mounted (etc.) by jailed root

[Mateusz Guzik]

On Wed, Apr 24, 2013 at 07:40:21PM -0600, Jamie Gritton wrote:
> On 04/24/13 19:22, Mateusz Guzik wrote:
> >On Mon, Apr 22, 2013 at 12:29:38PM -0600, Jamie Gritton wrote:
> >>On 04/22/13 11:39, Miroslav Lachman wrote:
> >>>>This already happens when jails are created using a jail.conf file. Any
> >>>>mounts there are unmounted as part of the jail removal process. Just
> >>>>recently I fixed it to properly do this unmounting in reverse order.
> >>>
> >>>Do you mean mounts defined in jail.conf or all mounts manually done by
> >>>root user in jail?
> >>>
> >>
> >>Ah, I see the difference. Yes, that's only for mounts in the jail.conf.
> >>For mounts done by the jail itself, I guess we would go off the mount
> >>record's credential. So is this something you expect to be happening
> >>entirely in the kernel?
> >>
> >
> >If we want to clean this up from userspace, we need to teach the kernel how
> >to export vnet and mount table of a jail and then it would be nice to teach
> >jls how to print it (or maybe create a separate tool - jstat?), and of
> >course jail(8) how to use this information to clean things up.
> >
> >Bonus points if jail(8) -r is able to clean up the jail without looking at
> >config file.
> >
> >I would prefer if the jail would be able to just die if no problems were
> >encountered and that is easly done with a kernel-only implementation,
> >but this still would benefit from features described above (the
> >difference would be that if someone wants to kill the jail, jail(8)
> >would only call jail_remove). If jail could not die because some clean
> >up operations failed, jls (or jstat) would show what resources are
> >remaining along with error message (say, fs could not be unmounted
> >because it was busy). And then the user can fix the problem and do
> >jail(8) -r to re-run kernel clean up or clean on his own (say, unmount
> >filesystems), which effectively should kill the jail.
> >
> >Thoughts?
> 
> If the kernel was able to export vnet and mounts, I would want jls to be
> the tool to show it. At least I wouldn't want to add another tool; a "-j
> jailname" option to df and ifconfig is an intriguing option. If jail(8)
> can get this information, then I would definitely want jail -r to clean
> it up; it doesn't matter whether or not there's a config file, since
> we're talking about things that are done outside the config file anyway.
> 

Lack of precision here, my bad. Clearly, if we just started a jail there
is no problem making it record everything it did.

With bonus points I was thinking about a jail started with, say,
mount.devfs. IIRC jail(8) just mounts devfs but this is not stored anywhere
and when such jail dies, we have an old mount noone knows about. So
bonus points for making a jail able to clean this up as well.

I'm fine with either jls or jstat.

> Vnet's little tricky because there are two kinds of interfaces in a vnet
> jail: those that were imported into the jail, and those that the jail
> has created itself. I don't know if the kernel knows anything about the
> difference between them, but it would make sense for the former to be
> returned to the host (which is the case) and the latter to be delete
> (which I have no idea about).
> 

That's for project taker to invesitage then.

> I still prefer that this be done in the kernel. For example, mount
> points have a credential attached, and that means that a removed jail
> will stick around as a zombie until it's unmounted.
> 

I prefer kernel implementation as well.

Since we seem to have an agreement of usefulness of the project, would
you be willing to add it to IdeasPage as a proposed GSoC project and
mentor a student (if any) who wants to work on this? I'm no fit for
mentoring.

Details of actual implementation can be worked on later.

-- 
Mateusz Guzik <mjguzik gmail.com>