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
[root@fedora ~]# exit
[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
[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
[niklas@fedora ~]$ podman exec --user root <your_container_name> chmod 4111 /usr/bin/sudo
Like this post if it helped you
Am having this problem on every new toolbox I have created for months. Does anyone know a permanent fix for this?
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.
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.