Add targeted supplementary GID mappings - #1834
Open
maxbeckmann wants to merge 3 commits into
Open
Conversation
Signed-off-by: Max Beckmann <37029778+maxbeckmann@users.noreply.github.com>
Signed-off-by: Max Beckmann <37029778+maxbeckmann@users.noreply.github.com>
Author
|
If this approach seems useful, I’d be happy to explore further directions, like automatically forwarding supplementary GIDs delegated to the user creating a toolbox, automatically resolving collisions, and preserving host group names. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This change lets a Toolbox container receive selected supplementary host groups through explicit GID mappings. A mapping can be supplied when the container is created:
$ toolbox create --gid-map 971:100000The option is repeatable. The same policy can be made persistent in
toolbox.conf, including the host-wide/etc/containers/toolbox.conf:Command-line mappings replace the configured list. If neither interface is used, container creation keeps its existing
--userns keep-idbehaviour.Each entry maps
HOST_GIDtoCONTAINER_GIDand adds the latter to the container's supplementary groups. Toolbox checks that the host GID is one of the calling user's supplementary groups and rejects duplicate or conflicting mappings. The host administrator must also delegate the host GID throughsubgid(5); for example:Mappings are fixed when a container is created, so existing containers must be recreated after changing them.
Motivation
This addresses the still-open Toolbox supplementary-group problem tracked by issue #1348, including the VirtualBox failure in #1589 and related device-access reports such as the USB printer in #1617. Toolbox recursively bind-mounts the host's
/dev, but the runtime normally clears the user's host supplementary groups while setting up the container. This makes some devices visible but unusable. Even more severely, it can prevent the container from starting at all when the runtime cannot traverse a group-restricted device tree.VirtualBox USB devices are one example. They are normally owned by
root:vboxusers, with0750directories and0660device nodes below/dev/vboxusb. Membership invboxusersgrants access on the host but is dropped by crun when starting the container unless instructed otherwise.As far as I understood, there is no general Podman-side fix foreseeable. Podman treats this as an authorization and namespace-policy decision, not a group it can transparently infer and expose. Membership in a host group permits a process to retain its existing credential, but it does not authorize namespace root to manufacture that credential later. A real mapping therefore requires prior administrator delegation through
/etc/subgid.Podman maintainers have improved the explicit mapping primitives in PR #18713, but have not adopted automatic mapping of all current supplementary groups. The general rootless group-mapping issue #13090 remains open, while the exact VirtualBox report #14284 was closed without a general solution. A more recent attempt to warn and recommend mappings, PR #29208, is still a draft with changes requested; its review again directs the simple case to crun's
keep-groups.Podman therefore already provides the mechanism needed by this change, while Toolbox must provide the opt-in integration and the host administrator must provide the authorization. This proposal replaces
--userns keep-idwith equivalent explicit mappings for the calling user's primary UID and GID, adds only the requested supplementary GID mappings, and passes their container-side GIDs through--group-add.This is deliberately narrower than crun's
--group-add keep-groups. Retaining all host supplementary credentials would change how the runtime establishes the container's group set and would hence displace container-native groups such aswheel, affectingsudoand login behaviour. Explicit mappings preserve normal OCI group handling, allow container-native groups to coexist, and make each additional host authority an administrator-approved opt-in through/etc/subgid.Relationship to existing Toolbox proposals
No existing Toolbox pull request implements targeted host-to-container GID mappings. This change is distinct from the three current proposals around
/devand supplementary groups:--group-add keep-groups. It is still open and stalled after its broader host group set invalidated existing group expectations.keep-groups, without checking for crun. It has changes requested, testing demonstrated loss ofwheel/sudo, and its author subsequently pointed to PR cmd/create: stop bind-mounting the host /dev , fixing VirtualBox issues #1778 instead./devduring OCI setup and projects selected entries later. This improves startup robustness and preserves container groups, but deliberately does not grant access to group-restricted host devices and relies on a hard-coded exclusion policy.The whole-host
/devbind originated in PR #119 to make dynamic host devices visible. This change retains that visibility model and addresses its missing authorization half. It neither preserves every host group nor creates a new policy for which/deventries Toolbox should expose: it maps only the groups explicitly selected and delegated by the host administrator.Why not adjust the device permissions with udev?
A host udev rule is a workable local fix. For
/dev/vboxusb, for example, it can add traversal permission to the generated directories and grant a named host user access to each device node with an ACL.That approach changes the permission policy of every offending device tree. It requires device- and vendor-specific rules, per-user ACLs, and careful handling of creation events and rule ordering. Each new group-restricted device family needs another exception.
A host-wide Toolbox configuration that pins mappings for device-controlling groups is a better policy boundary for this use case, in my opinion. It leaves the ownership and modes chosen by the device provider intact, authorizes the mapping once for the controlling group, and applies to every path governed by that group. In other words, it carries the host's existing group-based authorization into selected Toolbox containers instead of bending each device's permissions around the container runtime.