From owner-freebsd-jail@FreeBSD.ORG Thu Apr 25 15:04:10 2013 Return-Path: Delivered-To: freebsd-jail@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4D888398 for ; Thu, 25 Apr 2013 15:04:10 +0000 (UTC) (envelope-from jamie@FreeBSD.org) Received: from m2.gritton.org (gritton.org [199.192.164.235]) by mx1.freebsd.org (Postfix) with ESMTP id 36A521A57 for ; Thu, 25 Apr 2013 15:04:09 +0000 (UTC) Received: from guppy.corp.verio.net (fw.oremut02.us.wh.verio.net [198.65.168.24]) (authenticated bits=0) by m2.gritton.org (8.14.5/8.14.5) with ESMTP id r3PF48FX064183; Thu, 25 Apr 2013 09:04:08 -0600 (MDT) (envelope-from jamie@FreeBSD.org) Message-ID: <517945E3.4040701@FreeBSD.org> Date: Thu, 25 Apr 2013 09:04:03 -0600 From: Jamie Gritton User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120126 Thunderbird/9.0 MIME-Version: 1.0 To: Mateusz Guzik Subject: Re: automatic garbage collection of stuff mounted (etc.) by jailed root 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> In-Reply-To: <20130425145826.GA593@dft-labs.eu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-jail@FreeBSD.org X-BeenThere: freebsd-jail@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussion about FreeBSD jail\(8\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 15:04:10 -0000 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