Replies: 2 comments 1 reply
-
A binary being exec'd with an argv[0] of "buildah-in-a-user-namespace-in-a-user-namespace-in-a-user-namespace" suggests that buildah tried to run a copy of itself in a new user namespace with mappings applied, but the child process didn't have the privileges that its parent expected it to be given, so it tried again (and... again). Of course for the first child process, a number of the IDs that it would map into the new user namespace for its child aren't valid, because anything that wasn't mapped into the child's namespace is invalid. |
Beta Was this translation helpful? Give feedback.
-
Wait, are you already running as root? If so, how did the various capabilities get dropped? |
Beta Was this translation helpful? Give feedback.
-
I am trying to run buildah within a podman container within WSL to simulate a capability-restricted environment.
In my scenario the command
buildah unshare
is not able to create a new user namespace to mount a container, butunshare
is.WSL Environment
# podman --version podman version 4.6.2
Container Environment
The podman container is started via:
# podman run --rm -it --cap-drop ALL --cap-add CAP_SETFCAP,CAP_SETUID,CAP_SETGID,CAP_DAC_OVERRIDE --security-opt no-new-privileges --device /dev/fuse registry.fedoraproject.org/fedora-minimal:39 /bin/bash
After installing
buildah
andfuse-overlayfs
in the container:# buildah --version buildah version 1.32.0 (image-spec 1.1.0-rc.4, runtime-spec 1.1.0)
# fuse-overlayfs --version fuse-overlayfs: version 1.12 FUSE library version 3.16.1 using FUSE kernel interface version 7.38 fusermount3 version: 3.16.1
Running Buildah
The new container is created via:
# buildah from scratch working-container
Without User Namespace
Trying to mount the container fails as expected without a new user namespace:
Buildah Unshare
Trying to create a new user namespace via
buildah unshare
fails unexpectedly:Unshare
But creating a new user namespace via
unshare
works:GID / UID Mappings
The following subuids / subgids are defined:
# cat /etc/subuid /etc/subgid root:100000:655361 root:100000:655361
unshare
creates the following uid / gid mappings:# unshare --user --map-auto --map-root-user --mount cat /proc/self/uid_map /proc/self/gid_map 0 0 1 1 100000 655360 0 0 1 1 100000 655360
And according to the
buildah unshare
error message it tries to create the gid mappings0 0 1
and1 100000 655361
:If I interpret that correctly
buildah unshare
has an off-by-one error and the writing to the gid_map is rejected because it tries to map more gids than there are subgids?Question
My question is if I misunderstand / misuse
buildah unshare
, if this is intended behavior or if this is a bug.My expectation has been that the
unshare
command above would have the same result asbuildah unshare
.Beta Was this translation helpful? Give feedback.
All reactions