Supplementary groups are cleared instead of initialized from `/etc/group` when `--userspec` is used without `--groups` #3

New issue

Open

opened 2026-07-25 11:26:51 +00:00 by AnmiTaliDev · 0 comments

AnmiTaliDev commented

2026-07-25 11:26:51 +00:00

(Migrated from github.com)

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/root without --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.

### 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: ```go // 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 1. Have a user in `/etc/passwd`/`/etc/group` (inside the new root) who is a member of one or more supplementary groups. 2. Run `./warproot --userspec=<user> /path/to/root` without `--groups`. 3. 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.