Why is the default umask value for useradd in openSUSE set to 022?

Answering the question in your subject: OpenSuSE uses the traditional Unix umask setting, instead of the Debian-inspired one adopted by some other Linux distributions.

Editing /etc/login.defs should be sufficient to change it; this will not affect users currently logged in, nor is there any way for you to force such a change to programs that are currently running. It will also not affect users who have overridden it in their ~/.profile (or .bash_profile, .login, etc. as per their shell).

useradd is not involved with this; it is a per-process setting and the default is set during login (hence login.defs and not /etc/default/useradd).

The umask 022 (or 0022) is the commonly used umask for UNIX systems which use the traditional style of user account management. In the traditional style of account management, when a user is created, the user is given a default group which would be something like a team or department, or maybe as simple as "users". setgid directories (we could call them "team directories") do not work as expected, because the files are not writable for other team members unless the user makes them writable explicitly. This is not very practicable, especially when the files are opaque to the user, as it would be the case with, for example, a git repository. This is not considered a problem because ACLs provide a perfect solution for that.

The umask 002 (or 0002) is the commonly used umask for UNIX systems which use UPG - User Private Groups. When adding a user in an UPG system, the system creates a group with the same name and group id as the user name and user id. UPG is a Debian-inspired approach of user account management. As you've just experienced, UPG has some advantages when it comes to setgid directories - as long as users do not override their umask. ACLs are safe from that override.

The best solution is to refactor your user and group accounts and enable UPG, then you're "safe".

Warning! When you take a shortcut and simply change the umask in /etc/login.defs to 002 (or 0002) instead of 022 (or 0022), be aware that all files created by all users will per default now be writable by all other users in the same group. This is a security risk, so this is almost certainly not what you want.

One of the reasons for the introduction of the UPG system was that it allows administrators to configure a umask of 002 (or 0002) instead of 022 (or 0022) to easily facilitate the setgid bit for collaborative work on projects without the described security risk.

As far as I know, OpenSUSE does not offer a way to enable UPG during installation or YaST and the only way to use UPG is to purely use the command line for creating user accounts, after making the necessary change to /etc/login.defs: Change it to have USERGROUPS_ENAB yes. There's a pitfall here. UPG only works properly if the user id and the group id are identical. If you do that change to a running system, you will first have to change the ids of the existing groups, which involves re-assigning the groups to all files with these groups, and in the context of LDAP, NFS and NIS this can be a bit hairy.

Here's some further reading on this topic, which I found helpful when I was new to the topic of setgid vs. umask and UPGs:

• https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/3/html/Reference_Guide/s1-users-groups-private-groups.html
• https://wiki.debian.org/UserPrivateGroups

Most unix systems have a 022 umask, i.e. only the user can write files by default.

Having a 002 umask can be useful on systems where each user is in their own primary groups. However, this umask is fraught with dangers. It leads to a lot of support problems with .ssh directories that are group-writable and hence ignored by the SSH daemon. It leads to private files being leaked because they ended up belonging to a shared group. A lot of files end up belonging to the wrong group, so having them group-writable by default isn't such a good idea.

Umask and setgid directories were a bit of a hack in the days when this was the only way to facilitate sharing files between users. Nowadays, ACLs can do a far better job:

• Permission bits are associated to a particular group (instead of having separate settings for a set of group permissions and a choice of one group that these permissions apply to).
• The permissions of files don't need to depend on a user setting which users may override, they only depend on the permissions on the directory.
• Files can have permissions set for more than one group.
• Files can be shared between users who do not form a group.

Umask is obsolete, use ACLs.