sysroot bypass hardcoded /etc/passwd and /etc/group intercepts#215
Merged
Conversation
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
Max042004
suggested changes
Jul 18, 2026
| !strcmp(path, "/etc/group")) | ||
| if (!strcmp(path, "/etc/mtab")) | ||
| return true; | ||
| if (!strcmp(path, "/etc/passwd") || !strcmp(path, "/etc/group")) { |
Collaborator
There was a problem hiding this comment.
path_might_use_open_intercept() only checks that a sysroot is configured
(proc_sysroot_snapshot()), not that the sysroot actually contains
/etc/passwd / /etc/group. When it doesn't, the request falls through to
proc_resolve_sysroot_path_flags()'s host-literal fallback, which resolves
the literal host path — on macOS that's the real /etc/passwd /
/etc/group on the machine running elfuse.
Collaborator
Author
There was a problem hiding this comment.
Fix Details
- Added Existence Checks: Updated
path_might_use_open_interceptin path.c to perform astatexistence check on the guest sysroot-resolved files (${sysroot}/etc/passwd/${sysroot}/etc/group). The synthetic intercept is bypassed only when the file is present in the sysroot. - Updated Test Harness: Modified tests.mk to only stage
passwdin the fallback test's guest sysroot, leavinggroupabsent. - Added Assertions: Updated test-sysroot-host-fallback.c to verify that the absent guest
groupfile falls back to the synthetic group intercept instead of resolving to the host machine's/etc/group.
When a custom guest sysroot is configured, hardcoded intercepts on /etc/passwd and /etc/group shadow the actual files in the guest rootfs. This prevents guest processes from resolving users and groups that were added during package provisioning. We now check if a sysroot is active in path_might_use_open_intercept() and bypass the synthetic intercepts in that case, allowing the guest to read the actual user/group database from its rootfs. Fix sysprog21#188
Max042004
approved these changes
Jul 18, 2026
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
3 participants
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 a custom guest sysroot is configured, hardcoded intercepts on /etc/passwd and /etc/group shadow the actual files in the guest rootfs. This prevents guest processes from resolving users and groups that were added during package provisioning.
We now check if a sysroot is active in path_might_use_open_intercept() and bypass the synthetic intercepts in that case, allowing the guest to read the actual user/group database from its rootfs.
Fix #188
Summary by cubic
Prefer the guest sysroot’s
/etc/passwdand/etc/groupover synthetic intercepts when those files exist; otherwise fall back to intercepts. Fixes #188./etc/passwdin the sysroot wins and/etc/groupfalls back when absent; test setup now createssysroot/etc/passwd.Written for commit f1fd55d. Summary will update on new commits.