Why choose a umask of 002 over 022?

Question

I was cleaning up groups and permissions on my home system today, and re-familiarized myself with umasks. It seems that the default on my system (Ubuntu 18.10) is 002, but that for root it's 0022.

Ignoring the extra bit for the current purposes, this got me thinking. With a default of 002, any user in the group associated with my username will be able to edit my files. With 022, they won't. Now, I've never made use of this group before (nor root's group for that matter), so I have no idea why one would ever use it, nor which permissions would be appropriate in such a case.

In principle, why would you choose one of these options over the other? For bonus points, why would (this part of) the umask for root be different from ordinary users?

Answer 1

With a default of 002, any user in the group associated with my username will be able to edit my files.

The idea isn't that there would be other users in the user's personal group. The idea is that there might be groups for projects or such, and they might have multiple users as members. The group owner of the files can then be the project (not any of the users personally), enforced by setgid on the project directory. With the umask allowing for write access to the group, such files would be writable by all members of the project group.

It works something like this, assuming foo is a user using umask 002:

# [add user foo to group proj]
# mkdir /work/proj
# chmod u=rwx,g=rwx,o=,g+s /work/proj
# ls -ld /work/proj
drwxrws--- 2 root proj 4096 Jun 14 17:48 /work/proj/
$ umask
0002
$ cd /work/proj
$ echo "some data here" > file.txt
$ ls -l file.txt
-rw-rw-r-- 1 foo proj 15 Jun 14 17:51 file.txt

Note how the file was created a) with the group owner proj (because of the setgid on the directory), and b) with write permission to the whole group (because of the umask). Instead of requiring the users to have a proper umask, the directory could be set up with a default ACL, which replaces the function of the umask if set.

There's more on per-user groups and the umask at least here and in Red Hat's manuals (That's the manual for RHEL 4, the newer ones seemed to be briefer on the matter.) Also related is this q: Why does every user have their own group?

---

Nothing here prevents the users from manually messing up the permissions. It can't be prevented since the file owner can always change the permissions as they see fit. Nowadays people also more often use network services for collaboration, and such gymnastics with the file and directory permissions aren't necessary.