| |||||||||||||
Relationship with CLONE_NEWUSER?Relationship with CLONE_NEWUSER?Posted May 17, 2012 6:16 UTC (Thu) by geofft (subscriber, #59789)Parent article: User and group mount options for ext filesystems
It seems like this might fit in well with CLONE_NEWUSER / user namespaces, which allows an unprivileged user to set up a process (and its descendants) to have uids/gids completely separate from the uid/gids of the host, such that e.g. uid 0 in the namespace has none of the permissions that root has on the host machine. There's current work to set up a mapping between inner uids/gids and outer ones, so that a user can be assigned (by the sysadmin) a handful of unprivileged users, and map one of them to uid 0 inside the namespace and freely setuid() to other ones that they're allowed.
As might be implied by the CLONE_NEWFOO name, the primary use case of this is containers -- uid x in one container should have no relationship with uid x in another. (Within a user namespace, an unprivileged user can chroot since setuid binaries cause you to switch to that uid inside the namespace, not outside, etc. so the usual reasons not to let an unprivileged user chroot don't apply. The goal of user namespaces is essentially to let unprivileged users start their own containers.)
But there are a ton of applications for this, when it becomes useful, and one good one seems to be to associate a mount with a namespace. If I plug in an ext2-formatted external drive, I should be able to bind its uids/gids to a namespace I control, instead of to the root-level uid/gid namespace, and thereby be able to su to any user account inside it (and still have POSIX permissions be respected within that namespace). This certainly seems to help with the common case of USB sticks, since I can say that e.g. user 1000 in the root namespace maps to user 0 or 501 or whatever in the namespace associated with the mount, and then be able to directly read and write files and have things work as expected. It also has some benefits for other use cases, like being able to mount a device a container-owner controls a container and have permissions work properly there without impacting the host system.
(Log in to post comments)
|
|||||||||||||