Fix COW statx and execve for files in the upper layer#58
Merged
Conversation
Signed-off-by: Cong Wang <cwang@multikernel.io>
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.
Problem
With the seccomp COW backend active (any
--workdirrun withfs_isolation=None), a file created inside the sandbox was visible toopen()/read()andnewfstatat, but:statx(used byls,stat, most modern coreutils), returning ENOENTexecve, returning ENOENTThis broke the create-then-use / compile-and-run workflow (e.g.
gccwritinga.outthen the shell stat/exec'ing it).Root causes
handle_cow_statxreturnedContinuewhen the file existed in the upper layer, so the kernel re-ranstatxagainst the un-redirected lower path and saw nothing.execve/execveatwere not in the COW seccomp notification set, so the supervisor was never consulted and there was no COW handler at all.execve(/proc/self/fd/N)against the target file's real path, so the COW upper dir has to be in the allowlist.handle_cow_openhardcoded creation mode0o666, so a binary copied into the workdir landed in the upper layer non-executable.Changes
handle_cow_statx: runstatxon the resolved upper path in the supervisor and write the buffer back, mirroring the chroot statx handler. Handles AT_EMPTY_PATH.handle_cow_execforexecve/execveat: redirect to the upper file via an injected fd (/proc/self/fd/N) when the target resolves into the upper layer; pass through lower-layer files; return ENOENT for files deleted in the COW layer.execve/execveatto the COW notification set so the handler is reachable.handle_cow_open: honor the child's requested O_CREAT mode instead of0o666.Audited
readlinkandgetdents64: both resolve and write their results directly, so they do not have the same fall-through bug.Testing
Added two regression tests (statx on a COW-created file, exec of a COW-created binary) that fail before and pass after. Full suite green: 275 lib, 218 integration, 321 Python.
🤖 Generated with Claude Code