From owner-freebsd-jail@FreeBSD.ORG Mon Apr 22 15:14:26 2013 Return-Path: Delivered-To: freebsd-jail@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6E92FDFF for ; Mon, 22 Apr 2013 15:14:26 +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 54DDF10F0 for ; Mon, 22 Apr 2013 15:14:25 +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 r3MFDvqq088956; Mon, 22 Apr 2013 09:13:57 -0600 (MDT) (envelope-from jamie@FreeBSD.org) Message-ID: <517553B0.6010602@FreeBSD.org> Date: Mon, 22 Apr 2013 09:13:52 -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> In-Reply-To: <20130422091711.GA3115@dft-labs.eu> Content-Type: text/plain; charset=ISO-8859-1; 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: Mon, 22 Apr 2013 15:14:26 -0000 On 04/22/13 03:17, Mateusz Guzik wrote: > Hello, > > This is something that imho could be done by GSoC student. > > It is possible to allow jailed root to mount various filesystems. But > once all processes are dead, mounts done by jailed root that he didn't > clean up are still hanging around. > > As time passes and more stuff gets jailable we should expect problems > like this in different subsystems. > > So I propose that someone(tm) implements a solution which cleans this > stuff during jail destruction. > > One idea how to do it: implement a list with clean up operations. Using > mount example: you add a filesystem to be cleaned up after it is > mounted, you delete it after it is unmounted. When the jail is going to > die you just traverse the list backwareds and call cleaning functions, > in this case unmounting filesystems. Maybe this is is a bad idea in the > first place and it is better to take a look at mount tree and traverse > that, I don't know, you should investigate. :) Note that the code has to > be robust in case of errors (e.g. given fs may not be unmountable > because someone from prison0 is inside). > > Again, the goal is to have jails clean up automatically after anything > jailed root was permitted to do. > > Thoughts? 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. - Jamie