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.

10 thoughts on “027 umask — a compromise between security and simplicity

  1. James Le Cuirot

    As someone who’s been running with umask 077 for several years now, I have to say that Gentoo handles it remarkably well since its tools always switch to 022 when they’re supposed to. It’s other software that tends to have problems. It is a bit of a pain at times but not unbearably so or I would have switched back long ago.

  2. scytheman

    FEATURES=”usersync” drops rights after emerge –sync starts execution, right?

    1. Michał Górny Post author

      Yes, it does; but it does require one to gain those first. Syncing as a regular user allows me to sync without that hassle when I’m intending on doing something not requiring root privileges anyway (e.g. looking up a supposedly fixed ebuild).

  3. Pierre

    chmod o-rwx /home/foo

    ? While a child file/directory can be more permissive if at least read access to the parent directories is allowed (execute bit for directory listing if filenames are unknown), a directory without read access to third-parties will not allow any third-party to access it, so umask does not generally matter.

    You only have to think about doing the same for the other directories you may create elsewhere on your filesystem, if you don’t want to share them with other users on your machine without managing a dedicated group (this also slightly limits the risk of access during possible intrusions, but apparently privilege escalation is relatively easy once in, and of course the permission system is useless against LiveCDs and computer switching).

    Note the root user should really keep a 022 umask, so created system configuration files can be read/executed by non-privileged programs/users. Of course, if the configuration file contains private information, you can always try to restrict access more, on a case-by-case basis… But there is really no need at all to do it for most system configuration files, and it would be very tiring and sometimes risky.

    Also note that if you make archive files you may plan on sending to others or publishing globally (in a format preserving permissions, if configured to do so), you should really use a 022 umask for the files and directories archived, so as not to force more restrictive permissions on others (of course 777 files and directories are even more annoying), in case their archiver is not configured to apply the umask to extracted files (which can cause issues in some cases where permissions can be important, so it’s not a matter of configuring our archivers to always apply the umask).

    The permissions of the home directory created by `useradd` is defined in /etc/login.defs, but from the comment, I’m not sure if it is used for something else… I would suppose /etc/profile takes precedence…

    It should probably be added to the Gentoo Handbook anyway.

    1. James Le Cuirot

      What if you have a public_html directory? Then your home directory needs to be set to at least 701 and that makes the other contents potentially accessible if your umask is 022. Just a thought.

      1. Pierre

        704, or 705 for directory listing (not needed here on /home/foo, only /home/foo/public_html if desired). Read access is always required for any operation, including directory listing (if +x) and writes (if +w).

        However this is certainly a rare case for most users, and administrators configuring such features can take additional steps themselves (the most simple being the isolation of web directories from home directories, each subdirectory owned by the user managing it, and a group which the web server is part of, to avoid access by third-parties, notably to .htaccess/.htpasswd files, and other possible files which are not directly accessible through the web server and can contain private information). It should not influence defaults.

        For home use, with a web server not bound to any public address, and if you don’t mind to additional risk of privilege escalation, you could also make your web server run as root, so it could access any directory/file. But really the most simple solution is to put the web directories elsewhere.

        The umask is not reliable anyway. Programs can create files with different permissions whenever they want and modify these permissions after creation (I remember at least KDE I think, a few years back, created more permissive configuration directories and files than my umask, when I was testing a 077 umask…), and if you are not constantly checking them, there is a risk of access by others while you think you are safe. It’s better to forbid all access to the parent directory.

        It should also be noted that generally, programs which create configuration files with notably passwords, create them using a 077 umask anyway (sometimes only 027, which sure can be problematic if the user main group is “users”, but apparently most distributions today use a main group dedicated to the user), and they should, regardless of the user umask.

        For example, Claws Mail create its configuration/mail directory with 700 permissions (same for most directories/files inside this directory). gFTP too. GConf too. FileZilla, Gnome, Google Earth, Liferea, Flash, Firefox, MySQL, OpenSSH, Opera, Pidgin, SpamAssassin, Deluge too.

        1. Erik

          Pierre, I believe you have the directory permissions reversed. (I did some testing – and googling – to be sure.) Read access, +r, is required for a basic directory listing, but it’s +x that’s the important one; without it, you can’t do anything else. You could, however, have *just* the execute bit set, and then you can “invisibly” access – as well as individually list – a directory’s files and subdirectories provided you know their names. They can, as you mentioned, be more (or less) permissive… but again, that’s presuming the parent dir is set +x, not +r.

          You may also already know this, but for blog readers who don’t, I thought I’d mention an interesting, related factoid: A directory’s write bit does not affect whether or not you can alter the contents of that directory’s files, just whether you can create new files (or subdirs) and delete or rename existing ones. A directory that’s r-x (or, as explained above, –x) for your user/group/other category, for example, will still let you make changes to its files as long as the files themselves allow you write access.

    1. Michał Górny Post author

      Well, I meant Windows 9x-style desktops there mostly, where there were no clear concept of user separation. That ‘multi-user desktop’ can exist as well due to tasks like running a small webserver or so.

  4. Jack

    One problem I came across while having set umask 0027 in /etc/profile was the browsers could not respect the eselect java-nsplugin setting because the symlink was being created at a path only accessible to root.

Comments are closed.