Repository navigation
ocispec: make gVisor durable directory root mode 0777 - #3457
Merged
Tim Hockin (thockin) merged 1 commit intoNov 4, 2026
Merged
Conversation
nybidari
requested review from
Benjamin Elder (BenTheElder) and
Fabricio Voznika (fvoznika)
October 29, 2026 20:48
Fabricio Voznika (fvoznika)
approved these changes
Oct 29, 2026
gVisor durable directory volumes were mounted with tmpfs default 01777 because the mount hint specified no mode option. Set mode=0777 on the mount hint annotations to match the API guide and microVM. Signed-off-by: Nayana Bidari <[email protected]>
nybidari
force-pushed
the
gvisor-durdir-0777
branch
from
October 29, 2026 22:04
90e7d5e to
8c154ac
Compare
Collaborator
|
We actually have a way to express snapshot compatibility constraints, though nothing in main is using it yet. This might be a good use case. I think we don't want to outright break memory snapshots on v1.0.0-rc.1 but we can incrementally switch to this. |
16 of 23 tasks
Collaborator
|
Here's how to expression the snapshot compatibility:
|
2 tasks done
Collaborator
|
Benjamin Elder (@BenTheElder) If you decide this is M3 blocking, AND don't want to outright break memory snapshots on v1.0.0-rc.1, #3501 becomes M3 blocking as well. |
Benjamin Elder (BenTheElder)
approved these changes
Nov 4, 2026
Dmitry Berkovich (dberkov)
approved these changes
Nov 4, 2026
2 tasks done
Benjamin Elder (BenTheElder)
pushed a commit
that referenced
this pull request
Nov 5, 2026
Part of #3226. The API guide says a `durableDir` is created `0777`, like an emptyDir. On gVisor its root is `01777`. The volume is a tmpfs inside the sandbox, and its mount hint sets no mode, so it gets the tmpfs default. With the sticky bit, a user can't delete or rename another user's files in the volume's root. A durable dir created before this keeps `01777` when it is restored from a VOLUMES or ROOTFS snapshot, since the snapshot records its mode. Breaking Change: A gVisor actor whose template has a `durableDir` can't restore a MEMORY snapshot taken before this change. On a MEMORY restore, runsc checks that the sandbox spec's mount hints match the checkpoint, except `.source`. The new `dev.gvisor.spec.mount.<volume>.options` key doesn't match, so `runsc restore` fails and the actor goes to `CRASHED`. This includes MEMORY golden snapshots of these templates, and actors suspended while their worker rolls during the upgrade. No API restores such a snapshot without its memory. On upgrade: - Recreate affected templates so they take new golden snapshots. - Delete and recreate affected actors that hold a MEMORY snapshot from before the upgrade. A rollback breaks the same way. MEMORY snapshots taken after the upgrade fail to restore on the old worker. From v1.0.0, changes must keep upgrades and rollbacks working, so this has to land before then. AI use: AI-assisted, I reviewed and tested it. - [x] Tests pass - [ ] Docs updated Signed-off-by: Nayana Bidari <[email protected]> (cherry picked from commit 76cba32) Signed-off-by: dberkov <[email protected]>
1 of 2 tasks
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
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.
Part of #3226.
The API guide says a
durableDiris created0777, like an emptyDir. On gVisor its root is01777. The volume is a tmpfs inside the sandbox, and its mount hint sets no mode, so it gets the tmpfs default. With the sticky bit, a user can't delete or rename another user's files in the volume's root.A durable dir created before this keeps
01777when it is restored from a VOLUMES or ROOTFS snapshot, since the snapshot records its mode.Breaking Change:
A gVisor actor whose template has a
durableDircan't restore a MEMORY snapshot taken before this change. On a MEMORY restore, runsc checks that the sandbox spec's mount hints match the checkpoint, except.source. The newdev.gvisor.spec.mount.<volume>.optionskey doesn't match, sorunsc restorefails and the actor goes toCRASHED. This includes MEMORY golden snapshots of these templates, and actors suspended while their worker rolls during the upgrade. No API restores such a snapshot without its memory.On upgrade:
A rollback breaks the same way. MEMORY snapshots taken after the upgrade fail to restore on the old worker. From v1.0.0, changes must keep upgrades and rollbacks working, so this has to land before then.
AI use:
AI-assisted, I reviewed and tested it.