On Tue, Mar 31, 2015 at 6:07 AM, James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > On Tue, 2015-03-31 at 09:57 +0200, Alexander Larsson wrote: >> On fre, 2015-03-27 at 10:03 +0100, James Bottomley >> > >> > > On Fri, Feb 20, 2015 at 5:04 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: >> > > > It's currently impossible to mount devpts in a user namespace that >> > > > has no root user, since ptmx can't be created. >> > >> > This is where I stopped reading because it's not true ... because it is >> > possible, you just do it from the host as real root. >> >> The point is being able to set up a container as a user, not requiring >> the setup to be run as root at all. In my case container is a desktop >> application which will be started by the user, and will run as the user. >> There is no root involved in the call chain at all. > > I don't really like that use case: Most container setups are under the > control of an orchestration system (like LXC, OpenVZ or even Docker). > You typically get the orchestration system to do the dangerous > operations (mount being one of the bigger dangers) because it has the > capacity to vet them. I can see the value in allowing a user to set up > a container without an oversight system, but at the same time you're > increasing the security vulnerability of the system. Security is often > a result of policy, so now this embeds policy into the kernel. I > strongly feel we should define the list of things we expect an > unsupervised (as in with no orchestration system) container to do and > then revisit this once we've given it some thought. Try thinking "sandbox", not "container". The ability to create sandboxes without some root-installed orchestration is incredibly valuable. In any event, this ship sailed quite awhile ago. devpts is one of the smallish number of important missing features. --Andy _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers