On 2018-02-14, Enrico Weigelt <lkml@xxxxxxxxx> 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/>
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
