NurOS-Linux / NurOS-Linux/warproot
Supplementary groups are cleared instead of initialized from `/etc/group` when `--userspec` is used without `--groups`
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 2
- Forks
- 0
- PR merge metrics
- No merged PRs in 30d
Description
Description
When --userspec is provided without --groups, the code clears all supplementary groups instead of initializing them from the target user's actual group memberships:
// main.go:265-271
} else {
if err := syscall.Setgroups([]int{}); err != nil {
fmt.Fprintf(os.Stderr, "chroot: cannot set groups: %v\n", err)
logWarn("Failed to clear groups: %v", err)
os.Exit(1)
}
logInfo("Cleared supplementary groups")
}
Standard tools like chroot/su typically call the equivalent of initgroups() in this situation — looking up which groups the target user belongs to in /etc/group and applying that list. Here, the user silently loses all supplementary group memberships instead.
Impact
A process running as the target uid inside the chroot may unexpectedly lose access to files/resources that rely on group membership (e.g. group-readable/writable files), because none of the user's normal secondary groups are applied — and there's no indication to the operator that this happened beyond a debug-level log line.
Steps to reproduce
- Have a user in
/etc/passwd//etc/group(inside the new root) who is a member of one or more supplementary groups. - Run
./warproot --userspec=<user> /path/to/rootwithout--groups. - Inside the chroot, check
id— supplementary groups are empty instead of matching/etc/group.
Expected behavior
When --groups is not specified, supplementary groups should be initialized from the target user's memberships in /etc/group (an initgroups()-style lookup), matching the behavior of standard chroot/su implementations — or, if clearing groups by default is an intentional security choice, this should be clearly documented in --help and the README.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in main.go:265-271 and trace how --userspec and --groups determine supplementary groups. Reproduce the issue with a user and memberships in /etc/passwd and /etc/group, then verify the behavior with id inside the chroot. Done when the expected memberships are applied or the intentional clearing behavior is documented in --help and the README.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, linux
- Domain
- cli, operating-systems
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 58/100