Date: Thu, 25 Apr 2013 09:04:03 -0600 From: Jamie Gritton <jamie@FreeBSD.org> To: Mateusz Guzik <mjguzik@gmail.com> Cc: freebsd-jail@FreeBSD.org Subject: Re: automatic garbage collection of stuff mounted (etc.) by jailed root Message-ID: <517945E3.4040701@FreeBSD.org> In-Reply-To: <20130425145826.GA593@dft-labs.eu> References: <20130422091711.GA3115@dft-labs.eu> <517553B0.6010602@FreeBSD.org> <517575BF.8020305@quip.cz> <51758192.2050300@FreeBSD.org> <20130425012236.GB23151@dft-labs.eu> <51788985.7080406@FreeBSD.org> <20130425145826.GA593@dft-labs.eu>
next in thread | previous in thread | raw e-mail | index | archive | help
On 04/25/13 08:58, Mateusz Guzik wrote: > 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. No, jail(8) will properly unmount anything *it* mounts, including devfs. The only issue is when a jail is started with allow.mount (and perhaps any allow.mount.foofs), and then mounts its own filesystems. > 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. I'm trying to think if there are cases where this isn't the desired outcome, where someone might want to purposefully create a jail that leaves things mounted and then goes away. I can't come up with anything offhand, but then I sometimes get surprised by how people want to use jails. - Jamie
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?517945E3.4040701>