In Ubuntu 18.04 LTS, umask 0002 is the default for regular users.
It is defined in /etc/login.defs, but the definition is in two parts.
First, the UMASK setting determines the initial umask for both root and regular users. Note that the comments suggest that a later USERGROUPS_ENAB setting will modify it for regular users:
# Login configuration initializations:
#
# ERASECHAR Terminal ERASE character ('\010' = backspace).
# KILLCHAR Terminal KILL character ('\025' = CTRL/U).
# UMASK Default "umask" value.
#
# The ERASECHAR and KILLCHAR are used only on System V machines.
#
# UMASK is the default umask value for pam_umask and is used by
# useradd and newusers to set the mode of the new home directories.
# 022 is the "historical" value in Debian for UMASK
# 027, or even 077, could be considered better for privacy
# There is no One True Answer here : each sysadmin must make up his/her
# mind.
#
# 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.
#
# Prefix these values with "0" to get octal, "0x" to get hexadecimal.
#
ERASECHAR 0177
KILLCHAR 025
UMASK 022
And a bit later, in the same file:
# Enable setting of the umask group bits to be the same as owner bits
# (examples: 022 -> 002, 077 -> 007) for non-root users, if the uid is
# the same as gid, and username is the same as the primary group name.
#
# If set to yes, userdel will remove the user's group if it contains no
# more members, and useradd will create by default a group with the name
# of the user.
#
USERGROUPS_ENAB yes
Debian 11 has the exact same set-up, so Ubuntu 20.04 probably has it too. (I don't currently have a Ubuntu 20.04 VM at hand for checking.)
Classically, all users in a system used to share a primary group (often named users) and had a default umask of 0022 - or perhaps 0077 if the system required a hardened security posture.
This makes group projects somewhat awkward: once the sysadmin has created a group for a project and added the relevant users to it, before manipulating any files or directories intended to be accessible by a particular group, users must always remember to use newgrp or sg or else any new or copied files will not be writeable by other group members, which is annoying.
(If an accidentally non-group-writable file is in a group-writable directory, another group member user will be able to rename the problem file and make a copy of it, as long as the file is readable for the second user. Since the second user will be the owner of the new copy, they can now place the new copy where the problematic original was, and adjust its permissions to allow the group project to continue even if the person who accidentally made a project file non-group-writable... but it has been my experience that most users don't know this, and cry for help from the busy system administrator.)
As a result, the usergroups scheme was developed. It has two parts:
- For each regular user, a group is also allocated so that UID = GID. No other users will be assigned to that group.
- Regular users' default umask is changed to either
0002 or 0007 depending on required security posture.
Now, when a new group project begins, the sysadmin still needs to create a group and assign workspace for the group:
groupadd project
for user in user1 user2 user3; do usermod -a -G project $user; done
mkdir -p /shared/project
chgrp project /shared/project
chmod 2770 /shared/project # results in permissions drwxrws---
And now, the users won't need to remember anything special to have the files they create in /shared/project be fully accessible to the other group members: it Just Works.
The setgid bit on the top directory of the project causes all new files and directories to be assigned to the project group, and all directories created by the project members will also inherit the setgid bit. Because the users' umasks already allow group write access, the permissions will be correct for group work by default.
When the user manipulates their private files in their home directory, the group-access-enabled umask will cause no problems, because each user has their own primary group (UID = GID) which has no other members.
