While the GECOS field does the job, it is cumbersome to set it for all
users (new as well as existing) on multi-user systems. In that context,
the changes in trixie qualify as a severe security bug: I'm administering
a bunch of such systems, I upgrade them to trixie, and *poof*, users in
the same group can _write_ to each other's files and directories(!!!)
What's worse, the changes in trixie were made without much of a warning or
update to the documentation. I found multiple places where it is either
stated (paraphrased) that the default system-wide umasks are controlled by
a combination of UMASK and USERGROUPS_ENAB in login.defs , or that a line
like this in /etc/pam.d/common-session does the job:
session optional pam_umask.so umask=077
(see for instance
https://www.debian.org/doc/manuals/securing-debian-manual/ch04s11.en.html#idm1514
)
To be clear, this is not the case because usergroups has been enabled at
compile time and overrides umasks even on the pam_umask.so "command-line".
In order to work properly, "nousergroups" needs to be added to the
pam_umask line in /etc/pam.d/common-session :
session optional pam_umask.so nousergroups umask=077
Places where this is stated explicitly are hard to find at best; all
sources on the internet (including the Debian manual; see above) seem to
make the reasonable assumption that usergroups is not compiled into
pam_umask.so . You won't believe how much time it has cost me to find this
solution. In my opinion, this change in trixie is a blatant violation of
the Principle of Least Surprise.
