Date: Wed, 5 Feb 2014 19:56:36 +0000 From: "Robert N. M. Watson" <rwatson@FreeBSD.org> To: John Baldwin <jhb@FreeBSD.org> Cc: src-committers@freebsd.org, Doug Ambrisko <ambrisko@ambrisko.com>, svn-src-all@freebsd.org, Gleb Smirnoff <glebius@freebsd.org>, James Gritton <jamie@freebsd.org>, svn-src-head@freebsd.org, Alexander Leidinger <Alexander@leidinger.net> Subject: Re: svn commit: r261266 - in head: sys/dev/drm sys/kern sys/sys usr.sbin/jail Message-ID: <998DA3CF-C5A2-4492-8DF5-F1BF2451B860@FreeBSD.org> In-Reply-To: <2362081.WrjYmKeYu9@ralph.baldwin.cx> References: <201401291341.s0TDfDcB068211@svn.freebsd.org> <52EC4DBB.50804@freebsd.org> <20140203235336.GA46006@ambrisko.com> <2362081.WrjYmKeYu9@ralph.baldwin.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
On 5 Feb 2014, at 19:05, John Baldwin <jhb@FreeBSD.org> 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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?998DA3CF-C5A2-4492-8DF5-F1BF2451B860>