From 36e8752ef07e388fc1b81d2d4b0ae07b01c7275c Mon Sep 17 00:00:00 2001 From: dimko Date: Tue, 4 Aug 2026 21:32:32 +0300 Subject: [PATCH 1/2] MC-2035 fix: Say that a non-root container can modify files root created 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. --- magic-containers/persistent-volumes.mdx | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/magic-containers/persistent-volumes.mdx b/magic-containers/persistent-volumes.mdx index 4612b0c1..bde30a6f 100644 --- a/magic-containers/persistent-volumes.mdx +++ b/magic-containers/persistent-volumes.mdx @@ -117,10 +117,12 @@ CMD ["myapp"] | Operation | Result | |-----------|--------| | Read | ✅ | -| Modify | ❌ | +| Modify | ✅ | | Delete | ❌ | -Files created by a root process can be read but not modified or deleted by non-root containers. +Files created by a root process can be read and modified by non-root containers in the same pod. Every container in a pod shares a group that owns the volume, and files created inside it are group-writable regardless of the creating process's umask. + +Deletion is a separate question, decided by the directory rather than by the file - see [A note on deletion](#a-note-on-deletion) below. ### Non-root creates files, root accesses them @@ -147,19 +149,21 @@ Full access as both containers are the file owner. | Operation | Result | |-----------|--------| | Read | ✅ | -| Modify | ❌ | +| Modify | ✅ | | Delete | ❌ | -The accessing container is not the file owner. It can read files but cannot modify or delete them. +The accessing container is not the file owner, but it is in the group that owns the volume, and files inside a volume are group-writable - so it can read and modify them. Deletion is still restricted to the owner, see [A note on deletion](#a-note-on-deletion). ### Summary | Scenario | Read | Modify | Delete | |----------------------------------------|------|--------|--------| -| Root creates, non-root accesses | ✅ | ❌ | ❌ | +| Root creates, non-root accesses | ✅ | ✅ | ❌ | | Non-root creates, root accesses | ✅ | ✅ | ✅ | | Same non-root user | ✅ | ✅ | ✅ | -| Different non-root users | ✅ | ❌ | ❌ | +| Different non-root users | ✅ | ✅ | ❌ | + +Modification works across users because the volume is group-owned and its files are group-writable. Deletion stays with the file's owner - that is the sticky bit, described next. ### A note on deletion From 1a62b3a1f73482cd5941c15decb057b191a9fb5f Mon Sep 17 00:00:00 2001 From: dimko Date: Fri, 7 Aug 2026 18:34:26 +0300 Subject: [PATCH 2/2] MC-2035 fix: Scope the deletion rule to the volume's top level 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. --- magic-containers/persistent-volumes.mdx | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/magic-containers/persistent-volumes.mdx b/magic-containers/persistent-volumes.mdx index bde30a6f..b5f473a7 100644 --- a/magic-containers/persistent-volumes.mdx +++ b/magic-containers/persistent-volumes.mdx @@ -122,6 +122,8 @@ CMD ["myapp"] Files created by a root process can be read and modified by non-root containers in the same pod. Every container in a pod shares a group that owns the volume, and files created inside it are group-writable regardless of the creating process's umask. +This applies to files created from the point the volume is set up onwards. On volumes created before August 2026, files written earlier may still be readable but not modifiable by a non-root container, while newly created ones behave as described here. Recreating the volume, or changing the volume's security context, brings the older files in line. + Deletion is a separate question, decided by the directory rather than by the file - see [A note on deletion](#a-note-on-deletion) below. ### Non-root creates files, root accesses them @@ -167,7 +169,11 @@ Modification works across users because the volume is group-owned and its files ### A note on deletion -On Linux, whether a process can delete a file is determined by write permission on the **directory** containing the file, not by the file's own permissions. Because all pod containers share write access to the volume directory, a non-root container would ordinarily be able to delete any file inside it regardless of who created it. To prevent this, the volume directory is configured with the **sticky bit** — the same mechanism used by shared system directories such as `/tmp`. With the sticky bit set, only the file's owner or root can delete or rename a file, even with directory write access. The `Delete ❌` entries in the tables above rely on this. +On Linux, whether a process can delete a file is determined by write permission on the **directory** containing the file, not by the file's own permissions. Because all pod containers share write access to the volume directory, a non-root container would ordinarily be able to delete any file inside it regardless of who created it. To prevent this, the volume's top-level directory is configured with the **sticky bit** — the same mechanism used by shared system directories such as `/tmp`. With the sticky bit set, only the file's owner or root can delete or rename a file, even with directory write access. + +The sticky bit is not inherited, so it applies to files stored directly in the volume's top-level directory. Inside subdirectories that your application creates itself, deletion follows the ordinary rule again: any container in the pod can delete files there, including files another container created. If you rely on containers not being able to remove each other's files, keep those files at the top level of the volume, or set the sticky bit on your own directories (`chmod +t`) as part of your application's startup. + +The `Delete ❌` entries in the tables above describe the volume's top-level directory. ## FAQ