027 umask — a compromise between security and simplicity

Gentoo systems are shipped by default with umask 022 set in /etc/profile. It is documented there as quite realistic setting, in contrary to umask 077 which would be more secure. I personally disagree with this opinion, saying that 022 is basically suitable only for 100% desktop, single user systems. For a more common case of desktops, I’d stick with 027 instead.

What is an umask?

Wikipedia seems to have a pretty detailed explanation of umasks. Keeping it short, umask is a per-session setting which decides what permissions are set on newly-created files. Or, to be more exact, which permissions are removed from those files by default.

The 022 umask means that all users are allowed to read (and execute) files newly-created by the affected user but only the owner will be able to write them. On the contrary, 077 means that noone but the owner is able to read or execute newly-created files.

As the umask setting often involves configuration files as well, setting 022 globally means that other users will be able to read private user configuration files. On the other hand, 077 means that creating files intended for public reuse will always require using chmod to re-adjust the permissions.

What would 027 change?

The 027 umask setting means that the owning group would be allowed to read the newly-created files as well. This moves the permission granting model a little further from dealing with permission bits and bases it on group ownership.

First of all, we assume that each real user has his/her own, private, default group. All newly-created files — including configuration files — belong to that group. Considering that the only member of the group is user him-/herself, the files are not readable by anyone else.

Secondly, if some files are intended to be used by a specific group of users (and services), such a permission model can be easily achieved using auxiliary groups. For example, I keep the Portage tree owned by myself and the portage group. This way, I can perform emerge --sync using my restricted user and the resulting tree can be re-used by Portage when it drops privileges.

The group model has an additional advantage here. If you set the setgid bit on a directory, all newly-created files inside it will automatically belong to the same group as the parent directory. In other words, after performing:

chown -R :portage /usr/portage
find /usr/portage -type d -exec chmod g+s {} +

all newly-created files inside /usr/portage will automatically become readable to portage group.