[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. containers/podman#20445