On 15.04.19 17:50, Serge E. Hallyn wrote: Hi, >> I'm working on implementing plan9-like fs namespaces, where unprivileged>> processes can change their own namespace at will. For that, certain> > Is there any place where we can see previous discussion about this? Yes, lkml and constainers list. It's stalled since few month, as I'm too busy w/ other things. > If you have to disable suid anyway, then is there any reason why the> existing ability to do this in a private user namespace, with only> your own uid mapped (which you can do without any privilege) does> not suffice? That was actually one of the main design goals of user> namespaces, to be able to clone(CLONE_NEWUSER), map your current uid,> then clone(CLONE_NEWNS) and bind mount at will. Well, it's not that easy ... maybe I should explain a bit more about how Plan9 works, and how I intent to map it into Linux: * on plan9, anybody can alter his own fs namespace (bind and mount), as well as spawning new ones * basically anything is coming from some fileserver - even devices (eg. there is no such thing like device nodes) * access control is done by the individual fileservers, based on the initial authentication (on connecting to the server, before mounting) * all users are equal - no root at all. the only exception is the initial process, which gets the kernel devices mounted into his namespace. What I'd like to achieve on Linux: * unprivileged users can have their own mount namespace, where they can mount at will (maybe just 9P). * but they still appear as the same normal users to the rest of the system * 9p programs (compiled for Linux ABI) can run parallel to traditional linux programs within the same user and sessions (eg. from a terminal, i can call both the same way) * namespace modifications affect both equally (eg. I could run ff in an own ns) * these namespaces exist as long as there's one process alive in here * creating a new ns can be done by unprivileged user One of the things to make this work (w/o introducing a massive security hole) is disable suid for those processes (actually, one day i'd like to get rid of it completely, but that's another story). --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering info@xxxxxxxxx -- +49-151-27565287
