From ArchWiki
Jump to navigation Jump to search

umask vs. chmod parent directory

While this article covers the theory behind umask well, there is a practical example I wonder about: restricting the home directory on multi-user systems.

How would setting a user umask (e.g 027, as mentioned in Umask#See also) compare to restricting parent directories - in this case, the respective home folder - with chmod (e.g 750)? As far as I understand, in both cases users are not able to access eachother's files, but chmod may be simpler in that scenario (for example, it doesn't affect files copied to an external drive).

If a new umask is actually set, I wonder if it is good practice to change this globally as this also impacts files created by root (which tend to be world-writeable). Though makepkg uses an umask of 022 [1], so pacman should rsync the right permissions regardless.

Also, it seems /etc/login.defs sets an umask of 077 [2] (which is then overwritten by /etc/profile ? FS#15934 may be of note).

-- Alad (talk) 00:32, 30 August 2014 (UTC)

I'm quite sure you meant that files created by root tend to be world-readable. This is a sane default, there is no reason for security concerns as files that matter (e.g. private keys in /etc/ssh/) are handled explicitly. When a configuration file is created (e.g. /etc/locale.conf), one would most probably expect it to be also world-readable, which is why I think that changing umask for root is not a very good idea (however note that I don't live in a multi-user environment).
Regarding restricting home directory, you can always set it to e.g. 750 regardless of umask. It should be mentioned that when useradd -m creates the home directory, it applies the umask from /etc/login.defs, so it is created with 700 permissions by default.
Regarding selection of the "right" umask value, the permission management model needs to be considered as a whole. Many of the factors affecting the decision are not even described on ArchWiki (e.g. suid/sgid bits). Sometimes it might be easier to set umask temporarily for a session rather than changing some config, or even use chmod to explicitly set the permissions. Any suggestions are welcome, I don't have much practical experience.
Edit: One more note: the user's umask value affects also sudo's session (be it an interactive shell or just a running command), but there is an option to completely ignore user's umask - see Sudo#Permissive_Umask.
-- Lahwaacz (talk) 10:47, 30 August 2014 (UTC)
Yes, I meant that suggesting to change the root umask would be a bad idea.
A practical example I could think of where an actual umask is needed is a web server. If your website is stored in your home folder, alongside with other (private) files, you only want the public folder to be world-readable. But if you restrict the home directory (chmod 700), the website is not accessible. I'll see how I can add this to the article.
PS: In my case useradd did not follow the umask in /etc/login.defs - at least I had to chmod 700 it manually. -- Alad (talk) 23:47, 16 September 2014 (UTC)
Added a note [3] and cross-linked the section in Apache#User directories, let me know what you think. -- Alad (talk) 10:10, 3 February 2015 (UTC)
Looks good, thanks. Apache user directories definitely one common example worth mentioning, configuring an environment with shared write access is another one. Unfortunately they don't combine well because of the different demands on the umask. -- Lahwaacz (talk) 08:52, 15 February 2015 (UTC)