What are the cons, for having a restrictive umask of 077? A lot of distros (I believe all, except Red Hat? ) have a default umask of 022, configured in /etc/profile. This seems way too insecure for a non-desktop system, which multiple users are accessing, and security is of concern.

On a related note, on Ubuntu, the users' home directories are also created with 755 permissions, and the installer states that this is for making it easier for users to share files. Assuming that users' are comfortable setting permissions by hand to make files shared, this is not a problem.

What other downsides are there?

  • permissions seems more like it than 'umask' for tags... imo – xenoterracide Aug 19 '10 at 9:42
  • You can have up to 5 tags for a question, so why fight about it? :) Added the umask tag. – Warren Young Aug 19 '10 at 13:13
  • @warren because I dont' think we need tags for every single proper noun. when talking permissions in unix you have to include umask. – xenoterracide Aug 22 '10 at 18:14

022 makes things convenient. 077 makes things less convenient, but depending on the circumstances and usage profile, it might not be any less convenient than having to use sudo.

I would argue that, like sudo, the actual, measurable security benefit you gain from this is negligible compared to the level of pain you inflict on yourself and your users. As a consultant, I have been scorned for my views on sudo and challenged to break numerous sudo setups, and I have yet to take more than 15 seconds to do so. Your call.

Knowing about umask is good, but it's just a single Corn Flake in the "complete breakfast". Maybe you should be asking yourself "Before I go mucking with default configs, the consistency of which will need to be maintained across installs, and which will need to be documented and justified to people who aren't dim-witted, what's this gonna buy me?"

Umask is also a bash built-in that is settable by individual users in their shell initialization files (~/.bash*), so you're not really able to easily enforce the umask. It's just a default. In other words, it's not buying you much.

  • Everything after the first sentence of this answer is either an anecdote or an argument from authority. – FiddleStix Feb 4 at 11:41

The most obvious downside is when you start creating files/directories in a shared directory, expecting other users to access them.

Of course, it's only a matter of not forgetting to set the correct umask before doing stuff that need to be shared by all users.

Another caveat (not really a downside, once you are aware of it) is when you start doing sudo stuff such as installing local programs, ruby gems, python eggs (not OS manage packages obviously), creating configuration files, and so on.

You will get into trouble for the umask is inherited by the sudo session, so only root will be able to access files/dirs you create. sudo can be configured to automatically set the umask the way you want: this question is covered on superuser.com.

  • and the latter reason is a good reason to su - and make sure root has a different umask... but oh... ubuntu doesn't believe in root... – xenoterracide Aug 19 '10 at 9:41
  • 1
    @xenoterracide: sudo su - works fine. Ubuntu, like MacOSX, doesn't believe in a root you can just log into. Personally, I like having to say something like "Simon Says" for root commands most of the time. – David Thornley Aug 19 '10 at 11:21
  • @xenoterracide eh? what's your point? both sudo and su allow for root having a different umask. @David you can use sudo -i instead of sudo su - – zarkdav Aug 19 '10 at 18:34
  • 1
    @xenoterracide: Actually using the root command means I'm likely to type something into the wrong window. Using "sudo" means I have to specify I want this to be executed by root. I know perfectly well there's a root account, so I don't see where the false sense of security comes from. It's just one more little ritual (like sitting on my hands) that makes it less likely that I'll do something fatally stupid as root. – David Thornley Aug 19 '10 at 22:03
  • 1
    sudo and su, are tools, like any command. No need to mix feelings with utility. sudo brings flexible configuration, auditing, and usability to su. Of course one needs to know about the various possibilities and actually need them in order to recognize the benefits. I think this "false sense of security" you're talking about should be more appropriately targeted at Ubuntu "root account disabled" policy. That's the difference between a tool and a policy. One can make good arguments against a policy. Denying the usefulness of a tool because one does not agree with a policy is plain wrong. – zarkdav Aug 28 '10 at 10:48

Umask would not be appropriate if you are trying to control what other users can see from each other. However, if you have and work with numerous files that are sensitive to the point that being asked for permission to access them is less bothersome/risky than just letting people see whatever they want, than a umask of 077 would be a good idea.

I have some sensitive files on a file server I manage. I think setting a restrictive umask then having a periodic script, maybe a cron job to set more specific permissions to items in certain folders would be an ideal solution for me. When I set this up I will post back here, and let you know how it worked.

@[The guys bashing sudo] Start a new thread for it, it could take several threads of it's own and this thread is about umask.


Third-party applications that use their own installation systems may have built-in assumptions about the system default umask.

As a practical example, after updating an Oracle 10 database on a system that had the umask set to 077, the applications on the same system failed to access the database... because the libraries essential to the database clients, and the directories the libraries were located in, were now protected so that only the oracle user could access them, which was obviously not how things were supposed to work.

It turns out the Oracle updater process did not specifically take care that the permissions of the client libraries would allow other users to use them, but instead relied on the assumption that the files added by the updater would be created with umask 022 and so be usable by default. After a few judicious chmod -R a+rX commands for the appropriate directories, all was well again.

Granted, this could have been avoided by treating the oracle account as a special system account with standard umask 022, and restricting the umask 077 to actually login-able user accounts only... but I think this is a good example of how blanket "hardening" decisions can have unforeseen side effects.

.rpm and .deb packages carry explicit permission information for any files they contain, so they don't generally have the risk of errors of this type.


I have this line in my ~/.zshrc

umask 0077

setting it globally is probably not a good idea, but setting it as the default in your rc file is probably not going to hurt or even setting it as the default in the /etc/skel/.rc file. system wide will cause problems though.


It will cause problems on a server; for example, when having multiple applications running as different users trying to access files from different users. Like apache reading config files or pi-hole reading dnsmasq.conf. Just run it on users that could benefit from it like individual home directories, not explicitly set in /etc/profile.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.