On Fri, Oct 29, 2010 at 9:40 AM, Theo de Raadt <[email protected]> wrote: >> On Fri, Oct 29, 2010 at 02:29:50PM +0200, Ingo Schwarze wrote: ... >> This topic came up last year as well, including the same useradd/adduser >> confusion: >> http://kerneltrap.org/mailarchive/openbsd-tech/2009/5/8/5660874 >> >> "useradd really does that? A new group for every user? I think that >> is stupid behaviour." > > It is stupid behaviour, and I like the patch. If both these programs > go simpler and more alike, in the long term that would be better for > everyone.
Back in my pure sysadmin days, I found that when users all (or almost all) share a default group like "users", then it isn't easy enough for normal users to leverage other groups for shared access to files and directories. Because the default group is widely shared, everyone runs with a umask of 077 or 022; 'group' is effectively 'other'. As a result, users trying to share stuff via secondary groups have to remember to change umask or use chmod all the time. *I* didn't always remember to do that and I was the sysadmin; the teachers and students certainly didn't get it right consistently. Group-per-user setups solve this by letting people safely have a umask of 007 or 002. When they do work in a directory whose group is a secondary group, the resulting files are (and stay) writable by the group**. Permitting that change in default umask eliminates the requirement for manual changes and their cognitive load as the user moves between projects and directories. Fewer forgets and mistakes meant fewer emails to root asking for me to fix the perms on some file while so-and-so was on vacation, etc. Philip Guenther ** This was mostly on Solaris and Linux systems, so a pass across the system to do "chmod g+s" on all directories was necessary to get BSD-style "new files inherit group from directory", but that was a one-time cost.
