Resolve /proc/thread-self/* in syscall interception code. #101
+19
−9
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.
When intercepting system calls that use filepaths as arguments, those paths may be regular paths or may be paths under /proc (e.g., "/proc/self/fd/", "/proc/self/task//fd/", or "/proc/thread-self/fd/"). Sysbox was dealing properly with the first two but not with the last one (i.e., "/proc/thread-self/*").
This went unnoticed until a recent change in the OCI runc (commit 8e8b136c4923ac33567c4cb775c6c8a17749fd02) where it's now using "/proc/thread-self/" in mount system calls it issues. When that new OCI runc ran inside a Sysbox container, it failed with an error such as:
"error mounting "proc" to rootfs at "/proc": mount src=proc, dst=/proc, dstFd=/proc/thread-self/fd/8, flags=0xe: no such file or directory: unknown."
See nestybox/sysbox#879 for further info.
This commit fixes this by updating Sysbox to deal properly with syscalls that have "/proc/thread-self/*" in their arguments.