-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Regression] relative idmapped mounts prevent containers from starting in 4.4.0+ #17517
Comments
After a little bit of digging through the source code I think this is related to the change in fdcc225 which expects the podman/libpod/container_internal_common.go Lines 60 to 75 in fdcc225
This function is called in podman/libpod/container_internal_common.go Lines 77 to 118 in fdcc225
|
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 |
we were previously using an experimental feature in crun, but we lost this capability once we moved to using the OCI runtime spec to specify the volume mappings in fdcc225. Add the same feature to libpod, so that we can support relative positions for the idmaps. Closes: containers#17517 Signed-off-by: Giuseppe Scrivano <[email protected]>
PR here: #17522 |
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:
The text was updated successfully, but these errors were encountered: