From owner-freebsd-jail@FreeBSD.ORG Mon Feb 18 17:06:57 2013 Return-Path: Delivered-To: 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 ACD6242C; Mon, 18 Feb 2013 17:06:57 +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 66DAF9D8; Mon, 18 Feb 2013 17:06:57 +0000 (UTC) Received: from glorfindel.gritton.org (c-174-52-130-157.hsd1.ut.comcast.net [174.52.130.157]) (authenticated bits=0) by m2.gritton.org (8.14.5/8.14.5) with ESMTP id r1IH6uKm087773; Mon, 18 Feb 2013 10:06:56 -0700 (MST) (envelope-from jamie@FreeBSD.org) Message-ID: <51225FAF.9010507@FreeBSD.org> Date: Mon, 18 Feb 2013 10:06:55 -0700 From: Jamie Gritton User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.24) Gecko/20120129 Thunderbird/3.1.16 MIME-Version: 1.0 To: Mateusz Guzik Subject: Re: new jail(8) ignoring devfs_ruleset? References: <511E61F5.1000805@omnilan.de> <511EC759.4060704@FreeBSD.org> <5121EC52.5040502@omnilan.de> <51225642.2010501@FreeBSD.org> <20130218162956.GA1834@dft-labs.eu> In-Reply-To: <20130218162956.GA1834@dft-labs.eu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Harald Schmalzbauer , freebsd-stable , freebsd-jail 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, 18 Feb 2013 17:06:57 -0000 On 02/18/13 09:29, Mateusz Guzik wrote: > On Mon, Feb 18, 2013 at 09:26:42AM -0700, Jamie Gritton wrote: >> On 02/18/13 01:54, Harald Schmalzbauer wrote: >>> schrieb Jamie Gritton am 16.02.2013 00:40 (localtime): >>>> On 02/15/13 09:27, Harald Schmalzbauer wrote: >>>>> Hello, >>>>> >>>>> like already posted, on 9.1-R, I highly appreciate the new jail(8) and >>>>> jail.conf capabilities. Thanks for that extension! >>>>> >>>>> Accidentally I saw that "devfs_ruleset" seems to be ignored. >>>>> If I list /dev/ I see all the hosts disk devices etc. >>>>> I set "devfs_ruleset = 4;" and "enforce_statfs = 1;" in jail.conf. >>>>> Inside the jail, >>>>> sysctl security.jail.devfs_ruleset returnes "1". >>>>> But like mentioned, I can access all devices... >>>>> >>>>> Thanks for any help, >>>>> >>>>> -Harry >>>> >>>> devfs_ruleset is only used along with mount.devfs - do you also have >>>> that set in jail.conf? >>> >>> Thanks for your response. >>> >>> Yes, I have mount.devfs; set. >>> Otherwise I wouldn't have any device inside my jail. Verified - and like >>> intended, right? >>> Another notable discrepancy: The man page tells that devfs_rulset is "4" >>> by default. >>> But when I don't set devfs_rulset in jail.conf at all, inside the jail, >>> 'sysctl security.jail.devfs_ruleset': 0 >>> When set, like mentioned above, it returns the corresponding value, but >>> it doesn't have any effect. >>> How gets devfs_rulset handled? Does jail(8) do the whole job? I'd like >>> to help finding the source, but have missed the whole new jail evolution... >>> Inside my jails, I don't have a fstab, outside I have them defined and >>> enabled with "mount" - and noticed the non-reverted umounting. >> >> I found the problem - I noticed you mentioned 9.1-R, and took a look at >> devfs(5). On CURRENT, there's a mount option "ruleset", that isn't there >> on 9. >> >> So I'll have to get around it by running devfs(8) after the mount. I'll >> work on a patch for that. >> > > Why not MFC support for that mount option instead? That may be a better way around it, since either solution will require an MFC. It'd be nice to have a patch to jail(8) anyway, since just dropping in a new jail program is easier than dropping in a new kernel. I'll have to take a look at the devfs code and see if that was a reasonably small change. - Jamie