Toolbox: Containers don't start on Fedora CoreOS because there's no 'sudo' group inside the container

[Beholder101]

Hello,

I am trying to run toolbox on a Fedora CoreOS instance without any luck. The Toolbox is created as expected and without any errors, but entering the toolbox results in:

```toolbox: running as real user ID 1000
toolbox: resolved absolute path for /usr/bin/toolbox to /usr/bin/toolbox
toolbox: checking if /etc/subgid and /etc/subuid have entries for user core
toolbox: TOOLBOX_PATH is /usr/bin/toolbox
toolbox: running on a cgroups v1 host
toolbox: current Podman version is 1.8.2
toolbox: migration not needed: Podman version 1.8.2 is unchanged
toolbox: Fedora generational core is f31
toolbox: base image is fedora-toolbox:31
toolbox: container is fedora-toolbox-31
toolbox: checking if container fedora-toolbox-31 exists
toolbox: calling org.freedesktop.Flatpak.SessionHelper.RequestSession
toolbox: starting container fedora-toolbox-31
toolbox: /etc/profile.d/toolbox.sh already mounted in container fedora-toolbox-31
Error: unable to start container "fedora-toolbox-31": error looking up supplemental groups for container 673c0263ae66255178c9cd92cc47b61c5ebc19b9d27971408a3eacced61230c4: Unable to find group sudo
toolbox: failed to start container fedora-toolbox-31

When i cat /etc/group i can see sudo does exist and that my user core is a member
```root:x:0:
adm:x:4:core
wheel:x:10:core
sudo:x:16:core
systemd-journal:x:190:core
docker:x:982:core
core:x:1000:
fedora-coreos-pinger:x:981:
zincati:x:980:

Running the commands as sudo (sudo toolbox create) results in a whole other error i won't bring up here unless requested.

I am running the most recent release
```State: idle
AutomaticUpdates: disabled
Deployments:

• ostree://fedora:fedora/x86_64/coreos/stable
  Version: 31.20200407.3.0 (2020-04-21T19:37:39Z)
  Commit: 89e17cc21b6aa3bea8959d1e6957fda157168d57ba6805d8a36142184edc2901
  GPGSignature: Valid signature by 7D22D5867F2A4236474BF7B850CB390B3C3359C4
  ```

What am i missing here? What am i doing wrong?

Regards, Peter

[egeturgay]

I experience the same issue with the testing release Fedora CoreOS 31.20200420.2.0

[jlarriba]

Having exactly this issue with Fedora CoreOS 31.20200323.3.2

EDIT: And 31.20200407.3.0 too

[debarshiray]

Interesting.

Usually on Fedora, you only have the wheel group for sudo, while Debian has the sudo group for sudo. I guess CoreOS actually has both. What does the /etc/sudoers file look like on your CoreOS host? What's the exact group that's configured to be used with sudo? eg., on my Fedora Workstation I have:

%wheel  ALL=(ALL)       ALL

This error is coming from podman start ...:

Error: unable to start container "fedora-toolbox-31": error looking up supplemental groups for container 673c0263ae66255178c9cd92cc47b61c5ebc19b9d27971408a3eacced61230c4: Unable to find group sudo

[Beholder101]

Looks the same overhere. I pasted the last paragraph of the file here:

## Next comes the main part: which users can run what software on
## which machines (the sudoers file can be shared between multiple
## systems).
## Syntax:
##
##      user    MACHINE=COMMANDS
##
## The COMMANDS section may have other options added to it.
##
## Allow root to run any commands anywhere
root    ALL=(ALL)       ALL

## Allows members of the 'sys' group to run networking, software,
## service management apps and more.
# %sys ALL = NETWORKING, SOFTWARE, SERVICES, STORAGE, DELEGATING, PROCESSES, LOCATE, DRIVERS

## Allows people in group wheel to run all commands
%wheel  ALL=(ALL)       ALL

## Same thing without a password
# %wheel        ALL=(ALL)       NOPASSWD: ALL

## Allows members of the users group to mount and unmount the
## cdrom as root
# %users  ALL=/sbin/mount /mnt/cdrom, /sbin/umount /mnt/cdrom

## Allows members of the users group to shutdown this system
# %users  localhost=/sbin/shutdown -h now

## Read drop-in files from /etc/sudoers.d (the # here does not mean a comment)
#includedir /etc/sudoers.d

[egeturgay]

Could this be related to the fact that we're running rootless podman (under user core) and UID/GID mapping works a bit differently with subUIDs (due to mapping/overlapping) as explained here?
https://www.redhat.com/sysadmin/rootless-podman
From running the container manually with bash
$ podman top -l user,group,huser,hgroup
USER GROUP HUSER HGROUP
root root 1000 1000

[egeturgay]

this appears to be a fedora coreos specific problem, https://github.com/coreos/fedora-coreos-tracker/issues/458#issuecomment-620582289
and It may be best tracked there rather than here.

[jonas-hagen]

I get the same error on ArchLinux, when starting a podman container (or toolbox container):

$ podman --version
podman version 1.9.2
$ toolbox --version
toolbox version 0.0.90
$ podman start fedora-toolbox-32
Error: unable to start container "fedora-toolbox-32": error looking up supplemental groups for container xxx: Unable to find group sudo

sudo group and subuid, subgid are in place. I have never tried podman or toolbox before, so I cannot say "it worked before".

Happy to provide further details.

[ranfdev]

I've just installed the toolbox on fedora server 32, and i get the same error
error looking up supplemental groups for container xxx: Unable to find group sudo.
I'm running other containers with podman without any problems, but i can't start the fedora-toolbox:32 container, because of that error.

[abderrahim]

I had this error too, using Debian. toolbox works fine using podman from the repositories (v1.6.4) and fails when I installed the latest version (v1.9.3) manually. All my Fedora based toolboxes presented this error, but my Debian based ones didn't.

What happens is that when creating the container, toolbox passes --group-add sudo which is the group on my Debian host. And of course it fails because the sudo group doesn't exist in the fedora toolboxes.

The problem is that during toolbox create, utils.GetGroupForSudo() returns the for the host system which can be different from the toolbox (which is the case with Debian/Fedora CoreOS host and Fedora toolbox).

I don't think it's useful to add that given that toolbox init-container already adds the user to the "sudo group" in the container. Except maybe if the user exists and is not part of the group (I haven't investigated in detail what would be the consequences in that case).

[debarshiray]

Looks like the patch from https://github.com/containers/toolbox/pull/401 had an unintended side-effect.

Earlier, inside the container, we'd get:

⬢[rishi@toolbox ~]$ id
uid=1000(rishi) gid=1000(rishi) groups=1000(rishi),10(wheel)

... but now:

⬢[rishi@toolbox ~]$ id
uid=1000(rishi) gid=1000(rishi) groups=1000(rishi)

Notice how the wheel group doesn't get listed. It does show up in id rishi, and doesn't seem to affect sudo capabilities. However, this can still trip up users and programs alike.