IDMAPPED Mounts Aim For Linux 5.12 - Many New Use-Cases From Containers To Systemd-Homed
Kernel developer Christian Brauner has sent in the pull request looking to land IDMAPPED mounts functionality as part of the imminent Linux 5.12 merge window. Here is his summary on this big ticket feature that will be part of the next Linux kernel, assuming Linus Torvalds is in agreement with landing this code.
This patch series introduces idmapped mounts which has been in the making for some time. Simply put, different mounts can expose the same file or directory with different ownership. This initial implementation comes with ports for fat, ext4 and with Christoph's port for xfs with more filesystems being actively worked on by independent people and maintainers.
Idmapping mounts handle a wide range of long standing use-cases. Here are just a few:
- Idmapped mounts make it possible to easily share files between multiple users or multiple machines especially in complex scenarios. For example, idmapped mounts will be used in the implementation of portable home directories in systemd-homed.service(8) where they allow users to move their home directory to an external storage device and use it on multiple computers where they are assigned different uids and gids. This effectively makes it possible to assign random uids and gids at login time.
- It is possible to share files from the host with unprivileged containers without having to change ownership permanently through chown(2).
- It is possible to idmap a container's rootfs and without having to mangle every file. For example, Chromebooks use it to share the user's Download folder with their unprivileged containers in their Linux subsystem.
- It is possible to share files between containers with non-overlapping idmappings.
- Filesystem that lack a proper concept of ownership such as fat can use idmapped mounts to implement discretionary access (DAC) permission checking.
- They allow users to efficiently changing ownership on a per-mount basis without having to (recursively) chown(2) all files. In contrast to chown(2) changing ownership of large sets of files is instantenous with idmapped mounts. This is especially useful when ownership of a whole root filesystem of a virtual machine or container is changed. With idmapped mounts a single syscall mount_setattr syscall will be sufficient to change the ownership of all files.
- Idmapped mounts always take the current ownership into account as idmappings specify what a given uid or gid is supposed to be mapped to. This contrasts with the chown(2) syscall which cannot by itself take the current ownership of the files it changes into account. It simply changes the ownership to the specified uid and gid. This is especially problematic when recursively chown(2)ing a large set of files which is commong with the aforementioned portable home directory and container and vm scenario.
- Idmapped mounts allow to change ownership locally, restricting it to specific mounts, and temporarily as the ownership changes only apply as long as the mount exists.
Systemd is ready to begin immediately making use of IDMAPPED mounts as part of systemd-homed with portable home directories, container run-times containerd/runC/LXD want to use it to share data between the host and unprivileged containers, VirtIO-FS is also looking at using it for virtual machines.
More details on this big addition for the Linux kernel via this pull request. It's at a few thousand lines of code without all file-systems yet being ported over to supporting IDMAPPED. We'll see in the coming days what Torvalds thinks of the code and if he is ready to now mainline it for Linux 5.12.
8 Comments
