Image of the glider from the Game of Life by John Conway
Skip to content

Default Umask In Debian

I'm a bit bothered by something that no one can seem to give me a clear answer on: why is the default umask in Debian/Ubuntu '022'?

Let's think about this for a second. Back in the days of historical UNIX, probably for decades, the traditional file permissions of 'read', 'write' and 'execute' was sufficient security for both users and groups, and for the most part, they still are. We have other things in place, such as file ACLs and SELinux, but for the discussion of this post, I'm going to focus on just the traditional rwx.

Back during these days, users were thrown into the 'users' group. If a new user was created, it was a member of the 'users' group by default. If a system had 100 users, then there were probably 100 users in the 'users' group. Also, when a new file/directory was created, the user owned it, and the 'users' group had access. As such, the umask 022 needed to be set in place to keep anyone and everyone in the 'users' group from modifying the file. Technically, as it stands, there really isn't anything wrong with it, unless you don't want everyone in the 'users' group reading the file.

Along came User Private Groups (UPGs). This fixed the 'reading issue' by giving a unique private group to the user. If the user was 'aaron', then he also had an 'aaron' UPG. Same went with 'tom', 'jane' and 'spot'-- each user having their own private group with themselves being the only member of that group. So, the question follows: is the umask 022 still appropriate?

I'm arguing that it's not needed any longer. It certainly isn't hurting anything on the system, and the regular run-of-the-mill desktop or laptop user certainly isn't going to care. But what about production environments, where collaboration is big? What then? Well, if umask 022 is still set, then the permissions on a newly created file will have the read-only permission set for that group. Does this make sense? Let's break it down:

Suppose Tom creates a file in his home directory that he wants to share with a few co-workers, say an expense report. Suppose also that the default umask is 022. Well, when the expense report is created, he is the owner of the file, and his UPG, 'tom', is allowed access. Unfortunately, the 'tom' group only has read-access to the file, not write. Also, he's the only member of that group. So, not only does he have to add the coworkers to his group, so they can begin collaboration, but he also needs to change the file permissions to allow write access to the file. Suppose he creates many files, one after the other, each for the same collaboration with his UPG. Changing the file permissions to allow group write access can be annoying. So, he changes his umask to 002 to keep from doing so. A wise decision.

Are there any security holes in setting 002 system-wide? Not that I can see. UPGs initially only have one member in the group- the user that shares the same name. So, even if read, write and execute where set for the group permissions, unless anyone else is added to that group, it makes no difference, unless those same permissions were added to the 'other' rules. So, then why are we enforcing read-only on newly created files, when there is only 1 member in the group that has access to that file? It makes no sense. It completely defeats the purpose of UPGs.

Red Hat based distros, such as CentOS and SUSE have taken advantage of this, changing their default umask to 002. When will Debian, and Debian-based distros such as Ubuntu, follow suit? Can anyone give me a good reason why umask is set to 022 system-wide when the distro has implemented UPGs? I'd be interested to find out. Because as far as I can tell, this is a bug, and should be rightly filed as such.

{ 12 } Comments

  1. troll | October 24, 2007 at 12:57 pm | Permalink

    Modern operating systems use ACLs. Yawn. Moot rant is moot.

  2. Mike | October 24, 2007 at 2:02 pm | Permalink

    As far as I know, setting a default umask of 002 is current best practice. Debian and Ubuntu are my favorite distros--didn't know they didn't do this.

    (root might be an exception that would want 022.)

  3. Aaron | October 24, 2007 at 2:05 pm | Permalink

    @troll- Uh, I mentioned that there are better ways for controlling who has access to files, and that I wouldn't be covering them, such as FACLs. However, that still doesn't answer the question of why umask is set to 022 and not 002. Thus, supporting my belief that no one can give me a suitable answer to why this is the case.

    @Mike- Frustrating, isn't it? However, even root has it's on UPG, so it can also benefit from 002.

  4. Scott Balneaves | October 24, 2007 at 3:45 pm | Permalink

    Nope, not a bug. Safe behavior:


    sudo mkdir /home/shared
    sudo chown nobody:shared /home/shared
    sudo chmod 770 /home/shared

    cd /home/shared
    date > YouCanReadThisButNotWriteWhichIsTheSafeDefault

    I'd say the safe, read only group behavior is the preferred one.


  5. Robvdl | October 27, 2007 at 2:51 am | Permalink

    I was just wondering. Quite a few times I have wanted to setup a shared EXT3 partition that multiple users could write to, so long I add them to the same group. However, every new file or folder a user creates on this partition, it always sets the group permissions to "read only" by default. I can't have people right clicking every newly created file and folder and changing the group permisions to read+write manually. So in the end, after not being able to find a way around it, I usually end up using an NTFS partition as a workaround. This has frustrated me a bit, because I don't really want to use a non-UNIX filesystem such as NTFS just to work around this problem.

    I was wondering, if what you are talking about here, with the system wide umask, is what is causing this? i.e. that every newly created file or folder, the group permisions are set to "read only".

  6. Robvdl | October 27, 2007 at 3:01 am | Permalink

    After reading Ubuntu Demon's post, I just realised you can change the default umask in /etc/profile, so I guess that has just answered my question above. Nice.

  7. cyn0n | November 8, 2007 at 5:18 pm | Permalink

    you are totally forgetting that the user perms on that file are YOURS!!

    meaning I can execute whatever I want as YOU....

    sometimes I think reaching out to all you 'normal' people to use nix was a bad idea... whatever... there is just education to be had

  8. pr0le | November 23, 2007 at 6:42 pm | Permalink

    I'm with you on this one... this is one of those gotcha's I've found moving from RHEL to Ubuntu.

  9. Stefan | June 19, 2008 at 4:50 pm | Permalink

    It highly depends on the usecase which umask might be the right. For a shared hosting environment where everybody should only see hir files by default I would prefer 027.

  10. someone | September 15, 2009 at 8:13 am | Permalink

    A related issue: world-readable home dirs.
    dpkg-reconfigure adduser
    Lets you set or unset this. It only applies to new users.

  11. Mike Conigliaro | July 14, 2010 at 4:24 pm | Permalink

    just ran into this one today. and it looks like someone recently created a bug report for debian:

  12. Aaron | July 14, 2010 at 5:28 pm | Permalink

    Gee. I wonder who that was. 🙂

    You also might want to read this thread:

    and the follow-ups: and

    Should keep you busy for a while. 🙂

{ 3 } Trackbacks

  1. Christian » Default Umask In Debian | October 24, 2007 at 12:58 pm | Permalink

    [...] aaron wrote an interesting post today onHere’s a quick excerptIf the user was ‘aaron’, then he also had an ‘aaron’ UPG. Same went with ‘tom’, ‘jane’ and ’spot’– each user having their own private group with themselves being the only member of that group. So, the question follows: is the umask 022 … [...]

  2. Default umask « Ubuntu Demon’s blog | October 24, 2007 at 3:55 pm | Permalink

    [...] Filed under: english — ubuntudemon @ 10:55 pm This is a reaction to Aaron Toponce’s blog post about a better default for [...]

  3. [...] more here [...]

Post a Comment

Your email is never published nor shared.