idmapped mounts - kernel 5.12

[ykuksenko]

/kind feature

Description

Kernel 5.12 merged an IDMAPPED mounts feature. Is the podman project planning to make use of this?

Forgive me if this should be asked in a different location (runc/crun?). Mostly asking in case this went under the radar, I haven't seen any info about this around podman though containerd/containerd#4734 has had some movement.

Thank you.

[rhatdan]

We are familiar with it, and are planning on using it. We have not discussed how this will be used in RHEL yet.

[rhatdan]

@giuseppe WDYT?

[giuseppe]

AFAIK, it doesn't support yet overlay so that is not really useful at the moment.

How is containerd using the feature? Does it work only with vfs?

[brauner]

AFAIK, it doesn't support yet overlay so that is not really useful at the moment.

Fwiw, systemd is already using idmapped mounts for ext4 and xfs. I have a branch for overlayfs which I just need to rebase onto v5.13. I dropped this port from my initial patchset.
So how do you want to use this with overlayfs? Since overlayfs can be mounted inside of user namespaces since 5.11 what would idmapped mounts be used with it?

How is containerd using the feature? Does it work only with vfs?

Idmapped mounts currently work with ext4 and xfs so you can idmap any such mount. Take a look at e.g. systemd/systemd#19438
Is that what you were asking?

[rhatdan]

We want to take an underlying image stored with the system UIDS (IE UID 0==0, 1==1 ...) and map into different containers with these UIDs remapped to match the user namespace we are running them in. We only want to do this as readonly, if we want to write to any of these files in the image, we want overlay to copy up the files and write them with the User Namespaced UIDs.

We need to be able to do this in both rootfull (CAP_SYS_ADMIN) and rootless with User Namespace.

[giuseppe]

first of all let me rephrase "that is not really useful at the moment" -> "that is not really useful at the moment for us".

We could use it for -v /src:/dest:O where we currently use chown, but it won't help with mounting the container rootfs.

In our case, I think it will be easier to just use MOUNT_ATTR_IDMAP on the final overlay mount, that will be the container rootfs.

An alternative that could possibly help us is to create an idmapped bind mount for the entire storage and use it for accessing the overlay lower layers (the OCI image). I've not investigated this alternative yet as it requires non trivial changes in the storage library so I was just waiting for overlay support since I saw it was WIP and plug it more easily in what we have now.

[brauner]

We want to take an underlying image stored with the system UIDS (IE UID 0==0, 1==1 ...) and map into different containers with these UIDs remapped to match the user namespace we are running them in. We only want to do this as readonly, if we

So yes, that is exactly what this is for. For the most common case where as you said we're talking about system/or init uids it's as simple as attaching the container's userns to the detached mount.

Fwiw, idmapped mounts work outside of user namespaces as well. That was an explicit use-case for systemd and others. I.e. you could remap a fileystem in the init userns with this to e.g. have real root in a privileged container write as an unprivileged uid (say 1000) onto the disk, i.e. you could go andd create an idmapped bind-mount of your host's /opt at /mnt with a mapping of:

0 1000 1
1 1 1000
1001 1001 <range>`

and exposing this to a privileged container would mean that uid 0 aka real root creates files as uid 1000 on disk.

want to write to any of these files in the image, we want overlay to copy up the files and write them with the User Namespaced UIDs.

Right, so this sounds like overlayfs would be mounted on top of idmapped mounts, i.e. the lower layers would be idmapped and overlayfs would be mounted from inside the container.

We need to be able to do this in both rootfull (CAP_SYS_ADMIN) and rootless with User Namespace.

Right currently MOUNT_ATTR_IDMAP requires cap_sys_admin in init_user_ns but that will change in the future. I just want to wait until later in the year before we consider this. I don't want to jump the unprivileged gun too soon.

[brauner]

first of all let me rephrase "that is not really useful at the moment" -> "that is not really useful at the moment for us".

Thanks for that qualification. :) I appreciate that!

We could use it for -v /src:/dest:O where we currently use chown, but it won't help with mounting the container rootfs.

Because your rootfs mount is an overlayfs mount. Is the mount created from inside the container or is it created outside of the container?

In our case, I think it will be easier to just use MOUNT_ATTR_IDMAP on the final overlay mount, that will be the container rootfs.

Right, that's another case. That sounds like an idmapped mount of an overlayfs mount.
I have a branch that supports both, i.e. idmapped upper/lower directories and creating idmapped mounts of an overlayfs mount.

An alternative that could possibly help us is to create an idmapped bind mount for the entire storage and use it for accessing the overlay lower layers (the OCI image). I've not investigated this alternative yet as it requires non trivial changes in the storage library so I was just waiting for overlay support since I saw it was WIP and plug it more easily in what we have now.

[giuseppe]

We could use it for -v /src:/dest:O where we currently use chown, but it won't help with mounting the container rootfs.

Because your rootfs mount is an overlayfs mount. Is the mount created from inside the container or is it created outside of the container?

we create the rootfs mount outside of the container. That is kind of forced since the OCI runtime gets just the path to the container rootfs (so it must be already mounted by Podman) and create the mount namespace later.

[brauner]

We could use it for -v /src:/dest:O where we currently use chown, but it won't help with mounting the container rootfs.

Because your rootfs mount is an overlayfs mount. Is the mount created from inside the container or is it created outside of the container?

we create the rootfs mount outside of the container. That is kind of forced since the OCI runtime gets just the path to the container rootfs (so it must be already mounted by Podman) and create the mount namespace later.

Right, so the s_user_ns, i.e. the user namespace of the superblock is init_user_ns for overlayfs, right?

[brauner]

My point is that in principle it is possible to create idmapped mounts of filesystems that are mounted inside of a user namespace. It's just a matter of adapting the translation functions but if we can avoid it that'd be good too.

[giuseppe]

yes correct, at least when running as root.

For rootless we have an intermediate user+mount namespace

[giuseppe]

if you have some patches for the kernel, I can give them a try