Closed Syquel closed 1 year ago
After a little bit of digging through the source code I think this is related to the change in https://github.com/containers/podman/commit/fdcc2257df0fb0cb72d3fbe1b5aa8625955e1219 which expects the idmap
option argument to be %d-%d-%d
and does not account for relative idmappings.
https://github.com/containers/podman/blob/fdcc2257df0fb0cb72d3fbe1b5aa8625955e1219/libpod/container_internal_common.go#L60-L75
This function is called in parseIDMapMountOption
which should probably handle the relative idmapping.
https://github.com/containers/podman/blob/fdcc2257df0fb0cb72d3fbe1b5aa8625955e1219/libpod/container_internal_common.go#L77-L118
before we were relying on an experimental feature in crun, since there was no support for it in OCI. Now that there is idmapping support in the OCI runtime specs, we are using that to pass down the information.
I'll take a look and see if it is possible to add the same feature to Podman
Maybe this should not be implemented then and mounts / volumes should always be idmapped relatively to the user namespace.
I would prefer that solution because I can not imagine any use case where I would want to do an absolute idmapping or where that would even work.
Issue Description
If an idmapped mount is specified which is relative to the container user namespace the container cannot start in Podman 4.4.0+.
Example:
test-volume:/mnt/test:idmap=uids=@0-1001-1;gids=@0-1001-1
The container startup is aborted with the following error message:
Error: expected integer
This feature is documented in crun.1.md and worked in Podman 4.3.1.
Steps to reproduce the issue
Steps to reproduce the issue
podman --debug run -it --rm --volume 'test-volume:/mnt/test:idmap=uids=@0-1001-1;gids=@0-1001-1' fedora:37
Describe the results you received
The container startup is aborted with the error message
Error: expected integer
.Describe the results you expected
The container starts successfully and the volume is idmapped relatively to the container user namespace.
podman info output
Podman in a container
No
Privileged Or Rootless
Privileged
Upstream Latest Release
Yes
Additional environment details
No response
Additional information
Downgrading podman to version 4.3.1 resolves the issue.
Normal idmapped mounts which are not relative to the container user namespace are working in version 4.4.0.
Full debug log: