Default umask value

Ask Fedora
1

Hello,

the default umaks is set in /etc/login.defs to 022, but its value is also modified in the default /etc/bashrc to 002 for non-login shells:

if ! shopt -q login_shell ; then
    if [ $UID -gt 199 ] && [ "`/usr/bin/id -gn`" = "`/usr/bin/id -un`" ]; then
       umask 002
    else
       umask 022
    fi
fi

What is the reason to have a different umask value for login and non-login shells? Why should I have a more restrictive umask when I log into my workstation over SSH (login shell) and less restrictive when I use GNOME Terminal? The changelog in the setup RPM package spec file reveals that it’s been changed several times, but there is no reasoning. I have also found a bug report with a comment saying that /etc/bashrc shouldn’t set umask in most cases. Can someone explain that?

3 Likes
2

In the specfile changelog you link, 217523 – umask 022 breaks User Private Groups is a report that saying that “umask 022 for all breaks UPG configuration”.

“UPG”, or “User Private Groups” is a scheme that Red Hat Linux-based systems (like RHEL and Fedora Linux) follow, where each user account also gets a group account of the same name. Like, my username is mattdm and my primary group is also mattdm. Some other distros instead put all users in a users group. With this scheme, it’s safe to leave most files read/write by the group, because you’re the only one in it, and you can do this trick:

$ sudo mkdir /srv/teamshare
$ groups
mattdm wheel myteam
$ sudo chgrp myteam /srv/teamshare
$ sudo chmod g+ws /srv/teamshare
$ ls -ld /srv/teamshare
drwxrwsr-x. 1 root myteam 0 Nov 25 12:57 /srv/teamshare
$ touch /srv/teamshare/sharedfile
$ ls -l /srv/teamshare/sharedfile
-rw-rw-r--. 1 mattdm myteam 0 Nov 25 12:58 /srv/teamshare/sharedfile
$

So now, sharedfile in that directory can be edited by anyone in the group myteam — and this will be the automatic default permissions of any files created there. For example, if you were on the team, and made a file, it’d end up group-writable and owned by jwrona:myteam.

That’s pretty nifty and was a useful feature in shared-login systems in the 1990s and 2000-aughts. We generally don’t share systems in that way anymore, so arguably less important and we should just go for the more-restrictive default for all. However, because we still do user-private groups, there’s functionally not a difference in most cases anyway (hence “without gaining additional security” in that ancient bug report).

Also I notice a different bug that’s buried here. That $UID -gt 199 bit is based on the idea that user-account IDs start at 200. But if you look in /etc/login.defs, you’ll see that that’s actually 1000 — and that change is so long ago I don’t remember when.

2 Likes
3

I noticed that also recently. IIRC it was based on the fact that most system processes were run as users with UID <200 (At the time users UIDs started at 500).

Today I see a lot of different processes & UIDs in the passwd file that run system processes with UIDs < 1000. I am not sure why /etc/bashrc still sets that at $UID -gt 199.

I guess maybe system processes are still separated from app processes at the UID 200 boundary and apps started by the user are allowed a little more leeway in permissions.

I checked /etc/passwd and mine shows postgres, bacula, and sphinx all with UID < 1000 and all allowed login and not restricted by the /sbin/nologin command.

4

I’m, like, 97% sure that it’s just a bug — rather than reading it dynamically, it’s just hard-coded.

5

With umask set to 022 by default, the traditional way of setting a shared directory with setgid bit (as in your example) doesn’t work. So isn’t counterintuitive to adopt the UPG scheme and set umask to 022? Why not using 002 by default? Should ACL be considered the “modern” method to obtain the same result?

6