Consider not messing with namespaces and clone(2) in 'version'

[debarshiray]

Issue Description

podman version ends up doing various things with namespaces (at least user) and the clone(2) system call that sometimes end up with an EPERM in various build environments like Fedora's. It might be worth short circuiting those because ultimately it's just returning some relatively simple metadata.

The background is that Toolbx recently switched to using Cobra to generate the shell completions instead of static hand-written ones. This means that toolbox completion ... is run during the Toolbx build, and for various not-so-important reasons the start-up code in toolbox(1) calls podman version.

Steps to reproduce the issue

Try to build Toolbx 0.0.99.4 for Fedora 36 or 37 in the Fedora build system

Describe the results you received

When building Toolbx 0.0.99.4 in the Fedora build system, the podman version invocation hits an EPERM on both Fedora 36 and 37 (but works fine on F38 and F39/Rawhide). Here is a scratch build with toolbox --verbose completion ... and strace --follow-forks podman version sprinkled in the right places. Note that there are three toolbox completion ... invocations there, so everything is repeated three times.

Looking closely at the strace output in the build log, you will see:

[pid 1066178] geteuid()                 = 1000
[pid 1066178] getegid()                 = 425
[pid 1066178] clone(child_stack=NULL, flags=CLONE_NEWNS|CLONE_NEWUSER|SIGCHLD) = -1 EPERM (Operation not permitted)
[pid 1066178] write(2, "cannot clone: Operation not perm"..., 38cannot clone: Operation not permitted
...
...
[pid 1066178] write(2, "Error: cannot re-exec process\n", 30Error: cannot re-exec process
) = 30

My understanding is that this is coming from becomeRootInUserNS() in pkg/rootless/rootless.go, which calls reexec_in_user_namespace in pkg/rootless/rootless_linux.c, where the clone(2) is.

So far, I see that the Fedora 36 and 37 build environment is inside a chroot(2), while on Fedora 38 and 39 it's inside systemd-nspawn(1), and glibc-2.36-9.fc37 versus glibc-2.37-1.fc38.x86_64. I don't see any differences in libseccomp.

Describe the results you expected

podman version shouldn't encounter an EPERM and return the Podman version.

podman info output

One would have to run podman info on the Fedora build system, so I am skipping it.

podman-4.4.1-3.fc37; Fedora 37 on aarch64, ppc64le, s390x and x86_64

Similarly, on Fedora 36, which also includes armv7hl.

Podman in a container

No

Privileged Or Rootless

None

Upstream Latest Release

Yes

Additional environment details

A chroot(2) created by Mock 3.5 as part of the Fedora 36 and 37 build environment.

Additional information

I will try to work around this by avoiding the podman version call in Toolbx when generating the shell completions.

[Luap99]

Is there a reason why this isn't run as root? AFAIK as root we do not need to reexec at all.

That said it should be possible to make version not require the reexec.

[debarshiray]

Is there a reason why this isn't run as root?

What do you mean by this? People, including distribution build systems, usually don't do builds as root, because why use it if it's not needed? :)

Even though an RPM might eventually place files in system locations like /usr on the end user's system, that doesn't happen when the RPM is created by the build system. So, there's really no need for root.

[giuseppe]

I've opened a PR to not join the rootless userns with "podman version": #17684

although I am not sure how useful is that, if you cannot join a user namespace you cannot use podman rootless

[debarshiray]

I've opened a PR to not join the rootless userns with "podman version": #17684

Thanks, @giuseppe !

although I am not sure how useful is that, if you cannot join a user namespace you cannot use podman rootless

I suppose it's like dnf repolist. One can't really use dnf(8) without root, but some commands short circuit that.

In this particular case, podman version not messing with namespaces and clone(2) would have helped with the Toolbx build, but we already dodged that in Toolbx itself. Maybe it will prove useful at some other point in the future?