Thorsten Kukuk wrote:
We change explicit: USERGROUPS_ENAB from "yes" to "no". All other tools we provide and other distros do create usergroups by default, so I suggest to change it back to "USERGROUPS_ENAB yes".
The reasons for that seem pretty archaic and user private groups are normally accompanied with umask 002. This is explained eg here: https://lists.debian.org/debian-devel/2010/05/msg00315.html As stated there without the umask change it's kind of pointless though. If we also wanted to change the umask we'd have to be sure pam_umask etc is set up correctly to avoid upgrade situations where existing users with shared group end up having umask 002. Not sure how common setgid project directories are anymore anyway. The use case for RH adding that feature into shadow >20 years ago (RCS?) might have vanished. If so, we survived the times where that might have been important. So could just as well not bother and stay with our shared users group now. cu Ludwig PS: AFAICT shadow-utils version 19990827 introduced USERGROUPS_ENAB and the guy doing the package update back then apparently decided to turn it off and keep the previous behavior of SUSE Linux. Check the changelog of an old SUSE Linux before the time when the previous shadow package was dropped. :-) -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg)