Skip to content

containers.label_users is ignored by podman build #6160

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.

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

Closed
gucci-on-fleek opened this issue May 6, 2025 · 2 comments · Fixed by #6161
Closed

containers.label_users is ignored by podman build #6160

gucci-on-fleek opened this issue May 6, 2025 · 2 comments · Fixed by #6161

Comments

@gucci-on-fleek
Copy link

Even with containers.label_users set to true in containers.conf, podman build fails with SELinux permission errors.

Reproduction

$ id -Z
user_u:user_r:user_t:s0-s0:c0.c1023

$ cat /etc/containers/containers.conf

[containers]
label_users=true

$ podman run --rm -it fedora-minimal:latest /usr/bin/true

$ cat > Containerfile <<EOF
FROM fedora-minimal:latest
RUN /usr/bin/true
EOF

$ podman build --no-cache .
STEP 1/2: FROM fedora-minimal:latest
STEP 2/2: RUN /usr/bin/true
exec container process `/bin/sh`: Permission denied
Error: building at STEP "RUN /usr/bin/true": while running runtime: exit status 1

$ podman build --security-opt=label=role:user_r --security-opt=label=user:user_u --no-cache .
STEP 1/2: FROM fedora-minimal:latest
STEP 2/2: RUN /usr/bin/true
COMMIT
--> d28ad43735ae
d28ad43735ae6fbe6dee4c9ef43506d6a160d617cacc0d28bd1b514acde3aaf7

Logs

AVC avc:  denied  { transition } for  pid=551214 comm="crun" path="/usr/bin/bash" dev="overlay" ino=7626070 scontext=user_u:user_r:container_runtime_t:s0-s0:c0.c1023 tcontext=system_u:system_r:container_t:s0:c915,c1004 tclass=process permissive=0

Versions

I'm able to reproduce this on both Fedora 41 and Fedora 42:

$ cat /etc/os-release | grep PRETTY_NAME
PRETTY_NAME="Fedora Linux 41 (Workstation Edition)"

$ podman --version
podman version 5.4.2

$ uname --kernel-release
6.14.4-200.fc41.x86_64

$ rpm --query --queryformat='%{NAME}\t%{VERSION}\n' podman container-selinux containers-common selinux-policy-targeted | column --table
podman                   5.4.2
container-selinux        2.236.0
containers-common        0.62.2
selinux-policy-targeted  41.38
$ cat /etc/os-release | grep PRETTY_NAME
PRETTY_NAME="Fedora Linux 42 (IoT Edition)"

$ podman --version
podman version 5.4.2

$ uname --kernel-release
6.14.5-300.fc42.x86_64

$ rpm --query --queryformat='%{NAME}\t%{VERSION}\n' podman container-selinux containers-common selinux-policy-targeted | column --table
podman                   5.4.2
container-selinux        2.237.0
containers-common        0.62.2
selinux-policy-targeted  41.38
@rhatdan
Copy link
Member

rhatdan commented May 6, 2025

I take it, this works fine with podman run, only breaks with podman build?

@rhatdan rhatdan transferred this issue from containers/container-selinux May 6, 2025
@rhatdan rhatdan transferred this issue from containers/ramalama May 6, 2025
rhatdan added a commit to rhatdan/buildah that referenced this issue May 6, 2025
Fixes: containers#6160

label_users tells buildah and podman to maintain the user and role
from the SELinux label, the default is to change the user and role to
system_u:system_r.

With this change we end up with an unconfined_u user running the
container as unconfined_u:unconfined_r.

Signed-off-by: Daniel J Walsh <[email protected]>
rhatdan added a commit to rhatdan/buildah that referenced this issue May 6, 2025
Fixes: containers#6160

label_users tells buildah and podman to maintain the user and role
from the SELinux label, the default is to change the user and role to
system_u:system_r.

With this change we end up with an unconfined_u user running the
container as unconfined_u:unconfined_r.

I don't believe our CI/CD system can test this, because it runs with
system_u:system_r by default.

Signed-off-by: Daniel J Walsh <[email protected]>
@gucci-on-fleek
Copy link
Author

@rhatdan

I take it, this works fine with podman run, only breaks with podman build?

Yup, correct.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants