8000 Groups for root user not applied during podman exec when no explicit user specified · Issue #25610 · containers/podman · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
bodobrand opened this issue Mar 17, 2025 · 4 comments · Fixed by #25625
Closed

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

bodobrand opened this issue Mar 17, 2025 · 4 comments · Fixed by #25625
Assignees
@giuseppe
Labels
jira kind/bug Categorizes issue or PR as related to a bug.

Comments

@bodobrand
Copy link

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
  1. Build the image
podman build .
  1. Run the container (without the --user parameter).
podman run -itd $IMAGE /bin/sh
  1. Exec into the container (without the --user parameter).
podman exec -it $CONTAINER /bin/sh
  1. 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
@bodobrand bodobrand added the kind/bug Categorizes issue or PR as related to a bug. label Mar 17, 2025
@eriksjolund
Copy link
Contributor

I tried it out on Fedor 8000 a 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
Copy link
Member

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
Copy link
Member
mheon commented Mar 18, 2025

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 giuseppe added the jira label Mar 18, 2025
@giuseppe giuseppe self-assigned this Mar 19, 2025
@giuseppe giuseppe mentioned this issue Mar 19, 2025
Merged
@giuseppe
Copy link
8000
Member

opened a PR:

@BrewTestBot BrewTestBot mentioned this issue May 14, 2025
Merged
1 task
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@giuseppe giuseppe

Labels
jira kind/bug Categorizes issue or PR as related to a bug.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

libpod: fix handling of additional gids in exec giuseppe/libpod
4 participants
@giuseppe @eriksjolund @mheon @bodobrand
0