Groups for root user not applied during podman exec when no explicit user specified

[bodobrand]

Issue Description

Under certain conditions - specifically when the container relies on an implicit root user for each step - the Linux groups added to the root user in the Dockerfile do not apply to an interactive shell session started with podman exec -it ... /bin/sh. This issue also impacts any groups defined in the base image.

I am only able to reproduce this issue when the following conditions are met:

• Building from a Dockerfile WITHOUT any USER directive
• Podman run the image WITHOUT the --user parameter
• Podman exec into the running container WITHOUT the --user parameter

Note: As soon as I add --user or the USER directive at any step I cannot reproduce this issue anymore.

Steps to reproduce the issue

Steps to reproduce the issue

1. Create a Dockerfile with the following content:

FROM alpine

# for capsh --print
RUN apk add libcap

RUN addgroup -S appgroup && \
    adduser -S appuser -G appgroup && \
    addgroup root appgroup

2. Build the image

podman build .

3. Run the container (without the --user parameter).

podman run -itd $IMAGE /bin/sh

4. Exec into the container (without the --user parameter).

podman exec -it $CONTAINER /bin/sh

5. Verify that the root user does not have any group memberships in the current shell session:

# In the container
capsh --print | grep groups

Describe the results you received

/ # capsh --print | grep groups
groups=

Describe the results you expected

/ # capsh --print | grep groups
groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video),101(appgroup)

podman info output

Client:        Podman Engine
Version:       5.5.0-dev
API Version:   5.5.0-dev
Go Version:    go1.22.9 (Red Hat 1.22.9-2.el9_5)
Git Commit:    5eeaa437286c84ee29339911e68ec7957161b231
Built:         Tue Mar 11 01:00:00 2025
Build Origin:  Copr: rhcontainerbot/podman-next
OS/Arch:       linux/s390x

Podman in a container

No

Privileged Or Rootless

None

Upstream Latest Release

Yes

Additional environment details

No response

Additional information

No response

[eriksjolund]

I tried it out on Fedora CoreOS 43.20250211.91.0.

docker produces the expected result

$ docker exec -it 3dc9a64a83ff3d695cfa980d42aaceda89ed156c8b4ce141711afed4d2eb903f /bin/sh
/ # capsh --print | grep groups
groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video),101(appgroup)
/ # 

but podman doesn't

$ podman exec -it e85dc70e35c855105121165c381ee7132deb854806ad446d9cdbd4023f607dac /bin/sh
/ # capsh --print | grep groups
groups=
/ # 

$ rpm -qf /usr/bin/docker
docker-cli-27.5.1-1.fc42.aarch64
$ rpm -qf /usr/bin/podman
podman-5.4.0~rc3-1.fc43.aarch64
$

[giuseppe]

it seems to be caused by this condition: https://github.com/containers/podman/blob/main/libpod/oci_conmon_exec_common.go#L732

I don't understand it, @mheon why do we ignore execUser.Sgids when user is empty? Wouldn't be better if we consider execUser.Sgids everytime sgids is empty?

[mheon]

Commit introducing is #5349 which seems to be aimed at fixing a very similar bug to what was reported here - though I suspect you meant to point at the next line, which goes back even further, to the original introduction of our Conmon-based exec code in #3143 - so the condition appears to have originally been added by Peter around 6 years ago as part of our conversion to Conmon for exec? It looks like it was originally intended that it be unconditional so long as we actually had an execUser but a half-dozen refactorings made that no longer the case.

Anyways, this is a long-winded way of saying that I don't think there is a good reason and it's probably safe to change.

[giuseppe]

opened a PR:

• libpod: fix handling of additional gids in exec #25625