Support idmap for image volume mounts

[rhatdan]

Fixes: #23211

Does this PR introduce a user-facing change?

podman run --mount type=image now supports idmap mounts for rootful containers.

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: rhatdan

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [rhatdan]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[rhatdan]

@giuseppe This fix still gets a permission denied when doing the mount with --userns=auto, any idea why?

[packit-as-a-service]

Cockpit tests failed for commit 1a2a619. @martinpitt, @jelly, @mvollmer please check.

[giuseppe]

@giuseppe This fix still gets a permission denied when doing the mount with --userns=auto, any idea why?

idmap is not an option understood by the kernel. We need to create the idmapped mount through drivers.MountOpts.{UidMaps,GidMaps}. MountImage() doesn't offer to specify a mapping at the moment so we need a new API in c/storage first

[martinpitt]

That cockpit f40 failure was a temporary network outage. Please retry or ignore.

[giuseppe]

idmap is not an option understood by the kernel. We need to create the idmapped mount through drivers.MountOpts.{UidMaps,GidMaps}. MountImage() doesn't offer to specify a mapping at the moment so we need a new API in c/storage first

I had a look and it gets tricky in c/storage, as we will need to deal with an image mounted multiple times with different mappings. To avoid duplicating functionalities we already have for handling containers, we could create a temporary storage container based on the desired image and specify there the mappings

[Luap99]

To avoid duplicating functionalities we already have for handling containers, we could create a temporary storage container based on the desired image and specify there the mappings

If I remember correctly I saw a use case for rw image mount which actually changes the image content so if the changes are now temporary we we would break that.

[rhatdan]

rw image mounts are just an overlay mounted on the image, the underlying image is never changed.

[Luap99]

Ah right, I guess in this case a tmp storage copy container should be fine. I guess if do that we could also chown the image by default to the right userns then? Because idmap will not work rootless.

[giuseppe]

yes, it automatically uses recursive chown if there is no native idmap or fuse-overlayfs to do the mapping at runtime.

[openshift-merge-robot]

PR needs rebase.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[github-actions]

A friendly reminder that this PR had no activity for 30 days.