Messages in this thread | | | Date | Thu, 15 Feb 2018 07:39:33 +1100 | From | Aleksa Sarai <> | Subject | Re: plan9 semantics on Linux - mount namespaces |
| |
On 2018-02-14, Enrico Weigelt <lkml@metux.net> wrote: > But still I wonder whether user_ns really solves my problem, as I don't > want to create sandboxed users, but only private namespaces just like > on Plan9.
On Linux you need to have CAP_SYS_ADMIN (in the user_ns that owns your current mnt_ns) in order to mount anything, and to create any namespaces (in your current user_ns). So, in order to use the functionality of mnt_ns (the ability to create mounts only a subset of processes can see) as an unprivileged user, you need to use user_ns.
(Note there is an additional restriction, namely that a mnt_ns that was set up in the non-root user_ns cannot mount any filesystems that do not have the FS_USERNS_MOUNT option set. This is also for security, as exposing the kernel filesystem parser to arbitrary data by unprivileged users wasn't deemed to be a safe thing to do. The unprivileged FUSE work that Richard linked to will likely be useful for pushing FS_USERNS_MOUNT into more filesystems -- like 9p.)
-- Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH <https://www.cyphar.com/> [unhandled content-type:application/pgp-signature] | |