[Error] No sudo in any cross architecture containers

[devilock76]

Describe the bug When building an arm container on x86 or an x86 container on arm using Fedora as the host sudo fails

To Reproduce

$ distrobox create --name bionic-arm --image arm64v8/ubuntu:18.04 --home /home/myuser/db/bionic-arm --init --additional-packages "systemd libpam-systemd"
$ distrobox enter bionic-arm                                                                                                                                                                                (0.001206 hrs)
Starting container...                   	 [ OK ]
Installing basic packages...            	 [ OK ]
Setting up devpts mounts...             	 [ OK ]
Setting up read-only mounts...          	 [ OK ]
Setting up read-write mounts...
 Warning: failed to bind mount /run/host/mnt to /mnt
 Warning: Cannot bind mount /mnt to /run/host/mnt
 Warning: failed to bind mount /run/host/run/media to /run/media
 Warning: Cannot bind mount /run/media to /run/host/run/media [ OK ]
Setting up host's sockets integration...	 [ OK ]
Integrating host's themes, icons, fonts...	 [ OK ]
Setting up distrobox profile...         	 [ OK ]
Setting up sudo...                      	 [ OK ]
Setting up groups...                    	 [ OK ]
Setting up users...                     	 [ OK ]
Setting up skel...                      	 [ OK ]
Setting up init system...               	 [ OK ]
Firing up init system...                	 [ OK ]
$ sudo
sudo: effective uid is not 0, is /usr/bin/sudo on a file system with the 'nosuid' option set or an NFS file system without root privileges?
$ ls -l $(which sudo)
-rwsr-xr-x. 1 root root 136616 Apr  4  2023 /usr/bin/sudo
$ id
uid=1000(myuser) gid=1000(myuser) groups=1000(myuser),65534(nogroup)

Expected behavior sudo works

Desktop (please complete the following information):

• Are you using podman, docker or lilipod? podman
• Which version or podman, docker or lilipod? 4.8.3
• Which version of distrobox? 1.6.0.1
• Which host distribution? Fedora 39
• How did you install distrobox? dnf install distrobox also used dnf for qemu, qemu-user-static, qemu-user-binfmt and performed systemd restart systemd-binfmt

I have tried numerous variations and things such as: --root --unshare-all tried disabling selinux completely as well tried without libpam-systemd tried with focal instead of bionic at least for aarch64 -> amd64 using podman buildx functionality I can create a container that sudo works, just distrobox is the problem at the moment in this scenario

[MDr164]

The same issue occurs on Arch Linux as a host instead of Fedora so it is not caused by Fedora exclusively.

[89luca89]

I think there might be some problems with qemu+podman at this point

Can you run:

podman run --rm -ti --userns=keep-id --user 0 --name test arm64v8/ubuntu:18.04

then install sudo, and (while still running) in another tab do podman exec -ti --user $USER test and in that use sudo, and see if this presents the same problem?

[MDr164]

Still the same error message. Followed your steps as such:

• First terminal podman run --rm -ti --userns=keep-id --user 0 --name test arm64v8/ubuntu:18.04
• Inside container ran apt update && apt install sudo file
• Ran file on /usr/bin/sudo to make sure we're actually running arm64 binaries
• Opened second terminal and ran podman exec -ti --user $USER test /bin/bash
• Inside container ran sudo echo test

Still got: sudo: effective uid is not 0, is /usr/bin/sudo on a file system with the 'nosuid' option set or an NFS file system without root privileges?

OS: Arch Linux Container Engine:

Client:       Podman Engine
Version:      5.1.1
API Version:  5.1.1
Go Version:   go1.22.3
Git Commit:   bda6eb03dcbcf12a5b7ae004c1240e38dd056d24-dirty
Built:        Wed Jun  5 00:12:10 2024
OS/Arch:      linux/amd64

Qemu Version: 9.0.1

[89luca89]

Seems to me an upstream podman issue then, probably something to do with how the FS is shared with QEMU? I would be better to open an issue upstream then as this is not in distrobox power to fix

[MDr164]

Looks like this is somewhat intended and there are known workarounds listed in this discussion here. I agree that we can close the issue here. https://github.com/containers/podman/discussions/20445

[neobrain]

Just stumbled upon this issue as well.

Looks like this is somewhat intended and there are known workarounds listed in this discussion here. I agree that we can close the issue here. https://github.com/containers/podman/discussions/20445

I'm having trouble finding relevant workarounds in the referenced issue (some mention some C flag but that is internal to podman; then there's some podman machine ssh voodoo that doesn't apply on Linux). Are any of these directly applicable to distrobox or would they have to be applied to distrobox's implementation itself?

[neobrain]

Figured it out: The "C" flag actually belongs to the binfmt configuration set up by qemu-user. On my system, I now modified /usr/lib/binfmt.d/qemu-<EMULATED_ARCH>.conf by changing "FP" to "CFP". After running systemctl restart systemd-binfmt.

Use this with caution; I haven't done a deep dive into potential side effects. I just needed a one-time sudo and reverted this workaround right after.