Bug 1941380
| Summary: | Podman - secondary groups not available in container when using userns=keep-id | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Suhaas Bhat <subhat> |
| Component: | podman | Assignee: | Tom Sweeney <tsweeney> |
| Status: | CLOSED ERRATA | QA Contact: | Yuhui Jiang <yujiang> |
| Severity: | medium | Docs Contact: | Gabriela Nečasová <gnecasov> |
| Priority: | unspecified | ||
| Version: | 8.3 | CC: | bbaude, dornelas, dwalsh, gnecasov, jligon, jnovy, lsm5, mheon, pthomas, tsweeney, umohnani, ypu |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | podman-3.2 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2021-11-09 17:37:14 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1186913 | ||
|
Description
Suhaas Bhat
2021-03-22 01:18:17 UTC
I think this is not a bug in the sense that the container is behaving as expected. However, we should keep this open as it reveals an issue with our documentation that should be addressed. In brief: the container process has retained the groups of the launching process (`podman run` as the user in question), but does not have the appropriate permissions to actually add them to the rootless user namespace. The rootless user namespace, in case you are unaware, is how a non-root user on the system gains access to more than one UID and GID to launch containers; the user is assigned a number of users it can access in /etc/subuid and /etc/subgid, and these (plus the user's own UID and GID) are mapped into the rootless container. This mapping does not match the allocation on the host - by default the user launching the container has their UID/GID mapped to root in the container, and the subuid/subgid entries are added starting at UID/GID 1. The important bit here is that these are the only host UIDs and GIDs the container can actually see - we cannot add any others for security reasons. On to the groups that we leak: while the kernel does know that the process we've launched is in a user namespace, for the most part it is treated like any other process on the system. The list of groups it is present in is stored separately from the user namespace mappings - so a process can be part of a group, but not see it (the user namespace maps users not mapped into the namespace to 65534 - hence the output of your `id` command showing the process was part of 65534). If you were to get the container's PID on the host with `podman inspect` and then look at `/proc/$PID/status` on the host for that PID, I think you would see the list of groups you are expecting - the container still has access to them, but we can't actually see that inside the container. The unfortunate limitation here is that we cannot chown existing or new files to those groups. The kernel squashed them all down to a single GID that means "not mapped", and we can't chown to that because it can contain multiple UIDs and GIDs - the kernel won't let us. So this flag grants the container the ability to act as the original groups of the user launching, but not the ability to create new files with those UIDs or GIDs. We recognize that this is very confusing and blocks some usecases, but security requires that things be done this way. I have begun work on a PR to make this easier to do https://github.com/containers/podman/pull/9495 or at least easier for users to discover, Sadly between PTO and other work, I have not gotten back to it in a couple of weeks. Dan, seeing https://github.com/containers/podman/pull/9495 merged, can we consider this ready for QE? Yes Can we get qa ack please? Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Moderate: container-tools:rhel8 security, bug fix, and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2021:4154 |