Skip to content

storage: Document force_mask UID 0 mapping requirement#742

Open
ipilcher wants to merge 2 commits intocontainers:mainfrom
ipilcher:force_mask_uidmap_doc
Open

storage: Document force_mask UID 0 mapping requirement#742
ipilcher wants to merge 2 commits intocontainers:mainfrom
ipilcher:force_mask_uidmap_doc

Conversation

@ipilcher
Copy link
Copy Markdown

@ipilcher ipilcher commented Apr 3, 2026

force_mask doesn't work in rootless mode when the container's UID 0 is mapped to something other than the host UID of the user running the container. This PR adds a note about this requirement to containers-storage.conf.5.md.

Signed-off-by: Ian Pilcher <arequipeno@gmail.com>
@github-actions github-actions bot added the storage Related to "storage" package label Apr 3, 2026
@TomSweeneyRedHat
Copy link
Copy Markdown
Member

And more importantly, thanks for the PR @ipilcher !

@ipilcher
Copy link
Copy Markdown
Author

ipilcher commented Apr 4, 2026

I seem to have bollixed everything up by hitting GitHub's "Commit suggestion" button.

EDIT: I think I managed to fix it.

Signed-off-by: Ian Pilcher <arequipeno@gmail.com>
Co-authored-by: Tom Sweeney <tsweeney@redhat.com>
@ipilcher ipilcher force-pushed the force_mask_uidmap_doc branch from 011492b to 526cbe9 Compare April 4, 2026 14:23
Copy link
Copy Markdown
Contributor

@mtrmac mtrmac left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! This looks plausible but I’d prefer a LGTM from @giuseppe .

"force_mask" permissions.

- When force_mask is used in rootless mode with explicit UID mappings (e.g., `--uidmap`), the container's UID 0 must map to the host user's UID. fuse-overlayfs (see "mount_program" below) creates a FUSE mount that that is only accessible to the user who created it (the user running podman in this case). If UID 0 within the container is mapped to a different host UID (such as a subordinate UID from /etc/subuid), the OCI runtime (which runs in the user namespace) will not be able to access the FUSE mount.
- When force_mask is used in rootless mode with explicit UID mappings (e.g., `--uidmap`), the container's UID 0 must map to the host user's UID. The fuse-overlayfs (see "mount_program" below) storage driver creates a FUSE mount accessible only to the user who created it (the user running podman in this case). If UID 0 within the container is mapped to a different host UID (such as a subordinate UID from /etc/subuid), the OCI runtime (which runs in the user namespace) will not be able to access the FUSE mount.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fuse-overlayfs is a filesystem implementation, not a “storage driver” in the c/storage sense (overlay/vfs/btrfs). Maybe “filesystem”? “process”? Or revert to the previous version, which can be ambiguous about what exactly the thing is?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

storage Related to "storage" package

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants