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?


6 Answers 6


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.


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... Aug 19, 2010 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. Aug 19, 2010 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, 2010 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. Aug 19, 2010 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, 2010 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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .