From owner-svn-src-all@FreeBSD.ORG Wed Feb 5 19:56:50 2014 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E382F804; Wed, 5 Feb 2014 19:56:50 +0000 (UTC) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by mx1.freebsd.org (Postfix) with ESMTP id B69B5121A; Wed, 5 Feb 2014 19:56:50 +0000 (UTC) Received: from [10.0.1.9] (host31-51-142-185.range31-51.btcentralplus.com [31.51.142.185]) by cyrus.watson.org (Postfix) with ESMTPSA id CDF5746B09; Wed, 5 Feb 2014 14:56:41 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: svn commit: r261266 - in head: sys/dev/drm sys/kern sys/sys usr.sbin/jail From: "Robert N. M. Watson" In-Reply-To: <2362081.WrjYmKeYu9@ralph.baldwin.cx> Date: Wed, 5 Feb 2014 19:56:36 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <998DA3CF-C5A2-4492-8DF5-F1BF2451B860@FreeBSD.org> References: <201401291341.s0TDfDcB068211@svn.freebsd.org> <52EC4DBB.50804@freebsd.org> <20140203235336.GA46006@ambrisko.com> <2362081.WrjYmKeYu9@ralph.baldwin.cx> To: John Baldwin X-Mailer: Apple Mail (2.1827) Cc: src-committers@freebsd.org, Doug Ambrisko , svn-src-all@freebsd.org, Gleb Smirnoff , James Gritton , svn-src-head@freebsd.org, Alexander Leidinger X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 19:56:51 -0000 On 5 Feb 2014, at 19:05, John Baldwin wrote: > A short term solution that would permit non-security jails without = having to=20 > do the longer term work that Robert would like might be to add a new = per-jail=20 > flag that in effect means "no security at all". You would then modify = one=20 > place (prison_priv_check() in kern_jail.c) to treat a jail with this = flag set=20 > as if it wasn't jailed at all. This would clearly communicate to a = user what=20 > they were doing by enabling this flag (jail --root-me-please), and it = would=20 > also avoid future proliferation of new flags to add more optional and = obscure=20 > holes in jails. One path to this goal would be to better differentiate the idea of a = 'jail' from a more generic notion of a 'container'. I'm a bit loath to = use the latter term due to conflicts with the Linux convention which = uses 'container' to refer to something more like our 'jail', but in many = ways it would be useful. You could imagine having two variations on the = jail(8) command: today's jail(8) with security properties, and a new = container(8) from the same man page, but with only virtualisation, not = security properties. In general, there are two objections being raised here, which I think = you capture well: (1) an architectural concern about appropriate = implementation and its implications, and (2) appropriate = presentation/documentation for the user to prevent the significant = surprise they will get when they turn on an option without understanding = its implications. Robert=