Open samsaket7 opened 2 weeks ago
any ideas here @giuseppe
some weird interaction between binfmt and a file with capabilities (newuidmap).
Could you please share the output of grep . /proc/sys/fs/binfmt_misc/*
?
The default binfmt setup doesn't allow setuid binaries https://docs.kernel.org/admin-guide/binfmt-misc.html
C - credentials
Currently, the behavior of binfmt_misc is to calculate the credentials and security token of the new process according to the interpreter. When this flag is included, these attributes are calculated according to the binary. It also implies the O flag. This feature should be used with care as the interpreter will run with root permissions when a setuid binary owned by root is run with binfmt_misc.
We could of course change binfmt_misc configs in machine to set this flag.
If this capability exists, we should take advantage of it. Podman Machines are not expected to have network facing connections so the risk of turning something on like this by default is mitigated, and the downsides of people hitting it are big. One question though would this effect Rosetta based systems?
Yeah changing it for rosetta (x86_64) is simple, https://github.com/containers/podman-machine-os/blob/a52eab8a5fa6790495d90180d69ef94c09f6150e/podman-image-daily/rosetta-activation.sh#L8
We can add the flag there. Where I not sure is how to configure the qemu-user-static scripts for the other arches to make use it of. I would like it to be consistent and not just working with rosetta then.
Issue Description
I am experiencing an issue when trying to run amd64 Podman container inside a amd64 Podman container on macOS with Rosetta. The specific error occurs during the setup of user namespaces with newuidmap, resulting in the following error message: time="2024-06-19T00:52:32Z" level=error msg="running
/usr/bin/newuidmap 12 0 1000 1 1 1 999 1000 1001 64535
: newuidmap: write to uid_map failed: Operation not permitted\n" Error: cannot set up namespace using "/usr/bin/newuidmap": exit status 1Steps to reproduce the issue
Steps to reproduce the issue 1.Install Podman(5.1.1) on macOS M1.
podman run --arch=amd64 --user podman --privileged quay.io/podman/stable podman run --security-opt label=disable --arch=amd64 ubi8 echo hello
Describe the results you received
When running the nested Podman command with --arch=amd64, the operation fails with an “Operation not permitted” error during the newuidmap setup.
The same setup works correctly with --arch=arm64.
podman run --arch=arm64 --user podman --privileged quay.io/podman/stable podman run --security-opt label=disable --arch=amd64 ubi8 echo hello
Describe the results you expected
The newuidmap should correctly map user IDs without encountering permission issues, allowing Podman to run nested containers with --arch=amd64 on macOS with Rosetta.
podman info output
Podman in a container
Yes
Privileged Or Rootless
Rootless
Upstream Latest Release
Yes
Additional environment details
Additional environment details
Additional information
Additional information like issue happens only occasionally or issue happens with a particular architecture or on a particular setting