Sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set

Project Discussion
1

I can no longer use sudo in any of my toolboxes. What is wrong?

[niklas@fedora ~]$ sudo -i
[sudo] password for niklas: 
[root@fedora ~]# echo success
success
[root@fedora ~]# exit
logout

[niklas@fedora ~]$ toolbox --version
toolbox version 0.0.99.1
[niklas@fedora ~]$ podman --version
podman version 3.1.2
[niklas@fedora ~]$ hostnamectl | grep "Operating System"
  Operating System: Fedora 34.20210609.0 (Silverblue)

[niklas@fedora ~]$ toolbox create newtoolbox
Created container: newtoolbox
Enter with: toolbox enter newtoolbox
[niklas@fedora ~]$ toolbox enter newtoolbox
[niklas@toolbox ~]$ sudo -i
sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set
2

Outside toolbox:

[niklas@fedora ~]$ ls -lh /usr/bin/sudo
---s--x--x. 4 root root 182K  1 jan  1970 /usr/bin/sudo

Inside toolbox container

[niklas@toolbox ~]$ ll -lh /usr/bin/sudo
---x--x--x. 1 root root 182K Jan 26 21:09 /usr/bin/sudo

Workaround

[niklas@fedora ~]$ podman exec --user root <your_container_name> chmod 4111 /usr/bin/sudo

Like this post if it helped you :hugs:

1 Like
3

Am having this problem on every new toolbox I have created for months. Does anyone know a permanent fix for this?

4

I’ve not encountered this issue so far so there might be something specific to your setup triggering this but I don’t really know where to look for.

5

I just recreated this problem when doing a recursive chown on a home directory after I had already created a toolbox.

Essentially, there’s a lot of entries under/including ~/.local/share/containers/storage/overlay that must have a user:group of 100000:100000. If these get modified (such as the recursive chown I did), you simply break things.

Perhaps run the below to see if wrong user/group/permissions exist for problematic containers:

find ~/.local/share/containers/storage/overlay -type f -name sudo -executable -print0 | xargs -r0 ls -ld

As for fixing it, you can do surgery within the overlay directory or use the podman command you shared. It’s likely some files/directories will still have incorrect permissions though, so it’s possible there may be some side-effects to that.

I suppose you could also try using getfacl/setfacl to get an ACL dump from a working installation and apply it to a broken installation, but it still may not get you 100% there either.

I’m not sure how OP’s installation got to the state it is, but if a recursive chown was done at any point in time (intentional or not), that might explain things.

2 Likes