On Thursday 2021-08-05 15:05, Ludwig Nussel wrote: [https://email@example.com/message/...]
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. [...] 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. ... PS: AFAICT shadow-utils version 19990827 introduced USERGROUPS_ENAB and
The upstream changelog of shadow 19990827 has this to say:
- added support for "usergroups" feature often found in Linux distributions (if USERGROUPS_ENAB in login.defs set to "yes", uid != 0, uid == gid, and username == groupname, then set umask to 002 instead of 022)
What "Linux distributions"?
One can find USERGROUPS logic as early as Debian 0.93r6 adduser 1.94 (1995-10-09). This was at a time when Debian did not even use the shadow mechanism, with passwords being still in the second field of /etc/passwd. Not to mention _RH's_ shadow code, which I think they only jumped on with shadow-4.x, which is modern day age (2007+) by comparison.
Ironically, Debian never did set the setgid bit on the user's homedir (bug?), but it was present on /home (bug #2?).
# ls -al /home total 3 drwxrwsr-x 3 root staff 1024 Dec 13 13:21 . drwxr-xr-x 18 root root 1024 Dec 13 13:18 .. drwxr-xr-x 2 user user 1024 Dec 13 13:21 user
setgid project directories are kinda unnecessary since filesystem ACLs were added. usergroups logic should preferably be disabled by default at the root (in other words, in the RH shadow that exists today).