Janne Karhunen <janne.karhunen@xxxxxxxxx> writes: > On Tue, May 7, 2013 at 8:10 PM, Serge E. Hallyn <serge@xxxxxxxxxx> wrote: > >> Uh, I would say nack, and if you need this then a device >> namespace allowing you to 'pass' devices similarly to how you >> pass a physical nic to a child netns is a part of the answer. > > Hmm, 'slight' issue is that it does not really exist and that ns > can not even be properly specified as functionality (we tried > that earlier didn't we - everyone had different opinion on what > that ns should really do). So far it appears that we don't need a device namespace. As for most things the usual DAC permissions apply. The exceptions that I am aware of where we need something extra are cases where the device abstraction is simply insufficient and needs to be improved. You can pass real network devices between network namespaces. >> Your goals are not 100% clear to me. What is it about a user >> namespace that you want? > > I'm trying to experiment with a system that has init_ns size > of one tiny task and apart from that everything runs inside > containers. Because of this I need a way to elevate rights > of certain trusted applications inside user namespaces so > that they could operate against things requesting rights > from init ns. It will never be acceptable for tasks in a user namespace to have any rights outside of that user namespace. Elevating rights is the wrong model. The model very much needs to be how do we make a device safe for use by an unprivielged user. Most devices you can allow access to users in a user namespace with a simple chmod. You will also have the problem of how do you mount filesystems. Except for tmpfs I don't think there are any writable filesystems mountable in a mount namespace created by a user namespace. Your goal does sound interesting however. Eric _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
