https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271211
Bug ID: 271211
Summary: chroot -g inconsistently drops additional groups
Product: Base System
Version: 13.2-RELEASE
Hardware: Any
OS: Any
Status: New
Severity: Affects Many People
Priority: ---
Component: bin
Assignee: [email protected]
Reporter: [email protected]
finding:
/usr/sbin/chroot does NOT drop additional groups, if -G was NOT explicitely
specified as an argument and the calling process is in more than 1 OS group
(unclear assumption!).
current group memberships of the calling process can vary depending on where
scripts using it are called (e.g. system boot vs. interactive shell, see 13.2
example beyond).
this can lead to unexpected and even insecure results/behaviour.
proof:
------------------------------------------------------------------------
7.2-RELEASE
# id
uid=0(root) gid=0(wheel) groups=0(wheel),5(operator)
box:/# chroot -u user -g home / /usr/bin/id
uid=1000(user) gid=1000(home) groups=1000(home),0(wheel),5(operator)
------------------------------------------------------------------------
11.1-STABLE (1101501)
# id
uid=0(root) gid=0(wheel) groups=0(wheel),5(operator)
# chroot -u user -g home / /usr/bin/id
uid=1000(user) gid=1000(home) groups=1000(home),5(operator)
------------------------------------------------------------------------
12.2-STABLE (1202504)
# id
uid=0(root) gid=0(wheel) groups=0(wheel),5(operator)
# chroot -u user -g home / /usr/bin/id
uid=1000(user) gid=1000(home) groups=1000(home),0(wheel),5(operator)
------------------------------------------------------------------------
13.2-RELEASE (1302001)
# id
uid=0(root) gid=0(wheel) groups=0(wheel),5(operator)
# chroot -u user -g home / /usr/bin/id
uid=1000(user) gid=1000(home) groups=1000(home),0(wheel),5(operator)
------------------------------------------------------------------------
side note: 13.2-RELEASE during bootup looks like this:
# id called by RC script:
uid=0(root) gid=0(wheel) groups=0(wheel)
# same chroot command as above called by script:
uid=1000(user) gid=1000(home) groups=1000(home)
------------------------------------------------------------------------
as the base chroot code was introduced 2003, idk if this is really a (sec?)
bug/insecure behaviour.
https://cgit.freebsd.org/src/commit/usr.sbin/chroot?id=4fb3a3060cfe746c6c6699bc9b52d29594eb409b
if this works like expected, maybe an update to the manpage for clarity on
usage would make sense.
workaround:
i'd call chroot like this, which works as expected and mitigates this behaviour
at least for me:
/usr/sbin/chroot -g newgrp -G newgrp -u newusr / /path/to/exec
--
You are receiving this mail because:
You are the assignee for the bug.
