Date: Mon, 3 Feb 2014 23:53:32 -0800 From: Adrian Chadd <adrian@freebsd.org> To: James Gritton <jamie@freebsd.org> Cc: "src-committers@freebsd.org" <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, Gleb Smirnoff <glebius@freebsd.org>, Robert Watson <rwatson@freebsd.org>, "svn-src-head@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: <CAJ-Vmok55HLNey-UXO%2BzxK1dAUC4K-uN=CDcsSiXj-eF%2BaYgSg@mail.gmail.com> In-Reply-To: <52EC4DBB.50804@freebsd.org> References: <201401291341.s0TDfDcB068211@svn.freebsd.org> <20140129134344.GW66160@FreeBSD.org> <52E906CD.9050202@freebsd.org> <20140129222210.0000711f@unknown> <alpine.BSF.2.00.1401311231490.36707@fledge.watson.org> <20140131223011.0000163b@unknown> <52EC4DBB.50804@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 31 January 2014 17:28, James Gritton <jamie@freebsd.org> wrote: > I second the documentation route. Yes, it's true that this option > makes a totally insecure jail - at least one lacking the expected jail > security additions. But I think that while security is one of the > primary purposes of jails, it's not the only purpose. It should be > possible to have a trusted "master jail" that still takes advantage of > the encapsulation while allowing otherwise unsupported features such > as a desktop. No; the xorg probe and device hackery API should somehow be modified to support this kind of hackery. And/or a very specific API that doesn't simply require /dev/io and /dev/kmem to be exposed. > The distinction of whether certain devices are required to break out > of a jail with allow.kmem is something of a red herring - the fact is > that anyone who wants this level of access is going to have the > devices in place anyway. > > I suppose "obviate" wasn't the best word for the situation. Maybe > something that starts with "WARNING: ..." is in order. > > I'd like to re-submit the patch with only the documentation changed > (unless someone knows of something that would accomplish the same > goals with different code). But I'll run it by secteam@ first, and > abide by the consensus there. I really would rather see Xorg gain whatever abstraction is necessary to probe/attach/interface with a DRI API supported graphics card. So, this then becomes a question of whether this is needed for DRI API supported graphics cards, or whether you're trying to solve the general case (eg for nvidia stuff.) It would be nice to enumerate what's required for different ways of interfacing to the graphics subsystem(s). -a
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmok55HLNey-UXO%2BzxK1dAUC4K-uN=CDcsSiXj-eF%2BaYgSg>