MC-2035 fix: Correct what volume file permissions allow non-root containers to do - #393
Open
dimko-at-bunny wants to merge 3 commits into
Open
MC-2035 fix: Correct what volume file permissions allow non-root containers to do#393dimko-at-bunny wants to merge 3 commits into
dimko-at-bunny wants to merge 3 commits into
Conversation
The tables said root-created files can be read but not modified by non-root containers, and the same for files created by a different non-root user. That is not what the platform does: every container in a pod shares the group that owns the volume, and files inside it are group-writable whatever the creating process's umask was - which is the whole point of the group ownership and the default ACL the CSI driver sets on the volume. It also described the state volumes were actually left in while that ACL was silently not being applied (MC-2035), so the page matched the bug rather than the design. Deletion is unchanged and still restricted to the file's owner by the sticky bit; the tables now separate that from modification instead of lumping them together.
Contributor
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Workflows to automatically generate PRs for you. |
dimko-at-bunny
marked this pull request as ready for review
August 4, 2026 19:03
The page presented Delete as blocked across the board, on the strength of the sticky bit. The sticky bit is not inheritable and is set on the volume's top-level directory only, so inside subdirectories the application creates - which is where the data usually lives - any container in the pod can delete another's files. Measured on production volumes: the mount root is drwxrwsr-t, its subdirectories are drwxrwxr-x. Also notes that the modify behaviour describes files created from setup onwards, since files written on volumes that predate the fix stay as they were.
dimko-at-bunny
enabled auto-merge (squash)
August 14, 2026 20:54
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.
Type
Fix (documentation)
Why
The file-permissions tables state that a non-root container can read but not modify files created by root, and the same for files created by a different non-root user. That is not what the platform does: every container in a pod shares the group that owns the volume, and files inside a volume are group-writable regardless of the creating process's umask - which is the purpose of the group ownership and the default ACL the CSI driver applies.
The page effectively documented a bug rather than the design: between 2026-06-12 and CSI 0.0.146 that default ACL was silently never applied (MC-2035), so root-created files really did stay
644and unmodifiable. Vitali raised exactly this page while reviewing the fix.What
magic-containers/persistent-volumes.mdx-Modifybecomes ✅ for "Root creates, non-root accesses" and for "Different non-root users", in the per-scenario tables and in the summary. Each now says why (shared group ownership, group-writable files) and points at the deletion section.Deleteis unchanged: still ❌, still enforced by the sticky bit. The tables previously lumped modify and delete together, which is what made the claim look plausible.How tested
Behaviour verified on a node, including from inside a container through the bind mount: a file created with
umask 022comes out-rw-rw----and a directorydrwxrws---, so a pod-mate in the volume's group can modify it. Deletion remains owner-only.Checklist