Ansgar <ansgar@43-1.org> writes: > On Tue, 2022-03-08 at 12:29 -0700, Sam Hartman wrote: >> > > > > >> Take a look at https://salsa.debian.org/vorlon/pam/-/merge_requests/3 >> >> According to the history of that patch, we have some old consensus to >> move toward usergroups and a default umask of 0002 (except for root >> which gets 0022). > > On systems that don't use usergroups for all/some users, doesn't this > change make all files writable by other users by default? That would > seem like a very unsecure change on upgrades (or as a default). AFAIK systems that don't use usergroups are already not running in standard Debian configuration, since we default to USERGROUPS_ENAB being 'yes' in login.defs (and likewise USERGROUPS 'yes' in adduser.conf). If the sysadmin has chosen to change this, then a tighter umask is appropriate, but that's what they ought to get automatically reading this from login.defs: # If USERGROUPS_ENAB is set to "yes", that will modify this UMASK default value # for private user groups, i. e. the uid is the same as gid, and username is # the same as the primary group name: for these, the user permissions will be # used as group permissions, e. g. 022 will become 002. However, I suspect that something is a bit broken about this anyway, since I just tested and get a umask of 0022 when logging in via ssh to a system with USERGROUPS_ENAB 'yes'. The downside of having this set too tight is that it makes it harder to do the thing that usergroups is supposed to facilitate: Setting up directories that have shared group ownership, with the group s-bit set, such that all members of the group can have shared access to the directory. If the umask is too restrictive, then such shared directories give the appearance of working until someone tries to edit a file created by someone else, at which point they discover that its owned by the original user, and read-only for the shared group, which stops them editing it. I'd say that working out that this is due to the umask settings is a bit beyond most users. I seem to remember trying to work out where to fix this a few years ago, and discovering that we'd managed to break bits of the way it was meant to work, such that one ends up with a 0022 umask despite what it says in login.defs. Whatever we decide, we should try to make sure that there is a single place where the local admin can change the default and have it reflected in all the places that a umask might end up being set, be that in any of our Desktop environments, on the console, via ssh, and perhaps even as defaults for things like samba. We should also ensure that the conditional behaviour that's described in login.defs really happens, so that people can change away from usergroups and automatically get a safe umask setting to match. > (Though I think the current world-readable by default is already quite > bad. It seems like a unsafe choice on both single-user and multi-user > systems...) I agree -- cases such as ~/public_html not working well with such a umask are things that the user should notice and be easily able to discover how to fix, if they so wish. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/ http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg, GERMANY
Attachment:
signature.asc
Description: PGP signature