=== ucred / group changes in FreeBSD 15.0 Links: + link:https://lists.freebsd.org/archives/freebsd-hackers/2025-August/004825.html[freebsd-arch@ discussion] URL: https://lists.freebsd.org/archives/freebsd-hackers/2025-August/004825.html[] + link:https://cgit.freebsd.org/src/commit/sys/sys/ucred.h?id=be1f7435ef218b1df35aebf3b90dd65ffd8bbe51[Primary kernel change] URL: https://cgit.freebsd.org/src/commit/sys/sys/ucred.h?id=be1f7435ef218b1df35aebf3b90dd65ffd8bbe51[] + link:https://cgit.freebsd.org/src/commit/sys/kern/kern_prot.c?id=9da2fe96ff2ea227e4d5f03ef92b55aabeabb7fc[Primary userspace change] URL: https://cgit.freebsd.org/src/commit/sys/kern/kern_prot.c?id=9da2fe96ff2ea227e4d5f03ef92b55aabeabb7fc Contact: Kyle Evans + Contact: Olivier Certner FreeBSD 15.0 will change how supplementary groups are handled in both userspace and the kernel in FreeBSD 15.0 in a way that warrants additional attention and feedback. For some background: FreeBSD has historically tracked the effective group-ID of a process in the man:ucred[9] cr_groups array as the first element, with the rest of the array describing its supplementary groups. The natural consequence of this decision is that the arrays used in man:setgroups[2] and man:getgroups[2] follow the same format, and man:setgroups[2] has the documented side effect of setting the effective group-ID. The vast majority of other platforms do not exhibit this behavior anymore, including NetBSD and OpenBSD. macOS appears to be the only exception found in testing. The problem is that the vast majority of software in the FreeBSD Ports Collection comes from other platforms, where man:setgroups[2] and man:setgroups[2] operate purely on the supplementary groups. This kind of a behavior difference is very subtle and would need to be audited more carefully to be sure that we have not introduced a potential security issue in ported software. In FreeBSD 15.0, the primary user-facing change is that man:setgroups[2], man:getgroups[2], and man:initgroups[3] behavior will change to match other platforms, and users are requested to be extra vigilant in areas that may be affected as we proceed through the release cycle. In general, the expectation is that this change may: * Fix some small number of bugs where we would have lost either our expected effective group membership or one of the supplementary groups we should have been in * (Less likely) Introduce some even smaller number of bugs where something expected man:setgroups[2] to change our effective group membership but now it is just a supplementary group and our effective group-ID is unchanged Software included in the base system is largely unaffected or improved by this change, with OpenSSH being a notable example of a link:https://cgit.freebsd.org/src/commit/?id=239e8c98636a7578cc67a6f9d54d14c71b095e36[strange bug] caused by the historical implementation.