toolbox: Container doesn't start because user.Current() fails inside the entry point
Describe the bug
When trying to enter the container fedora-toolbox-35 created using
toolbox create --distro fedora --release 35
I get the error
$ toolbox enter fedora-toolbox-35
Error: invalid entry point PID of container fedora-toolbox-35
To have a better error message I tried to attach to the container using podman instead of toolbox and got the error:
$ podman start --attach --interactive fedora-toolbox-35
Error: failed to get the current user: user: lookup userid 0: invalid argument
This error is returned by toolbox whenever Golang’s user.Current() gets an error when calling getpwuid_r.
Steps how to reproduce the behaviour
- toolbox create --distro fedora --release 35
- toolbox enter fedora-toolbox-35
Expected behaviour toolbox should start the default user shell inside a container.
Actual behaviour
toolbox exits with error code 1 and prints the error Error: invalid entry point PID of container fedora-toolbox-35.
Screenshots If applicable, add screenshots to help explain your problem.
Output of toolbox --version (v0.0.90+)
toolbox version 0.0.99.3
Toolbox package info (rpm -q toolbox)
toolbox-0.0.99.3-2.fc34.x86_64
Output of podman version
Version: 3.4.2
API Version: 3.4.2
Go Version: go1.16.8
Built: Sun Nov 14 00:16:48 2021
OS/Arch: linux/amd64
Podman package info (rpm -q podman)
podman-3.4.2-1.fc34.x86_64
Info about your OS Fedora Silverblue 34
Additional context
Add any other context about the problem here.
When did the issue start occurring? After an update (what packages were updated)?
If the issue is about operating with containers/images (creating, using, deleting,…), share here what image you used. If you’re unsure, share here the output of toolbox list -i (shows all toolbox images on your system).
IMAGE ID IMAGE NAME CREATED
ab8bc106d4a7 <none> 2 months ago
d8a734db8c5c registry.fedoraproject.org/fedora-toolbox:34 7 months ago
40b181c70b73 registry.fedoraproject.org/fedora-toolbox:35 4 weeks ago
If you see an error message saying: Error: invalid entry point PID of container <name-of-container>, add to the ticket output of command podman start --attach <name-of-container>.
About this issue
- Original URL
- State: open
- Created 2 years ago
- Comments: 19 (8 by maintainers)
Hey, @angiglesias , my apologies, I didn’t have to time get back to this, but thanks for continuing to dig into it.
This is expected:
… because Fedora 35 inside the container uses glibc-2.34. Binaries, in this case
mount(8), that were built against it can’t be run against the Fedora 34 host with glibc-2.33.As far as I can make out, we are going through
current()in go.git/src/os/user/cgo_lookup_unix.go, which ends up callinggetpwuid_r (0, ...). So, you could try to write a small C program that callsgetpwuid_r (0, ...)and run it asroot:rootinside the container and see what’s going on.Yes, that’s a smart way to test!
We could conditionalize this line to only run on the host:
… because we don’t use
currentUserinside the container. However, before changing anything, I want to understand exactly what’s going on here.It makes sense that it’s trying to look up the user for UID 0, because
toolbox init-containeris running asroot:rootinside the container. The question is, why doesuser.Current()think that it’s an invalid argument.Given that this is rootless Toolbx, UID 0 inside the container isn’t the same UID 0 as on the host. There’s a user namespace and some other non-0 UID from the host has been mapped to 0 inside the container. I am wondering if there’s something wrong there.
Could you please show me the
/etc/subuidand/etc/subgidfiles from your host?And the UID/GID mappings for the namespace? Inside the container:
… and from the host:
The
toolbox init-containerentry point is the first process started inside the container bypodman startasroot:rootin terms of the container’s user namespace. It keeps running asroot:root, and doesn’t change to something else.The interactive shells offered by
toolbox enterare invoked separately throughpodman execand those always run as the same user on the host, which is most likely not root.@patriziobrunops did something go wrong with your comment? 😃