On Thu, Aug 05, Ludwig Nussel wrote:
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.
I completly disagree that you need a umask 002 if you have a private group. Many wrote here already that they prefer a "private" group and then let the admin add selected users, who should be able to access the files. In this case you don't want that they can access and edit everything in your home, but only what you give free. So private group and default umask of 022 doesn't seem to conflict for me.
But this would be a good reason for private groups and umask 002: https://lists.debian.org/debian-devel/2010/05/msg00254.html
But it requires devel groups and not, as some discussed here, addition of additional users to the private group.
Since we cannot change the past, I still think the best is to use private groups, keep umask 022 (or existing users get a security problem) and if people use UPG and devel groups, they can set UMASK in their login profile to 002.
That's what RedHat is doing, too. Which also means, the claim in the debian thread, that RedHat is using umask 002 is wrong.
For security and collaboration reasons, I really like the UPG idea with devel groups best, even if this means that this users have to set their own UMASK.
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.
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)