Default umask value

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

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

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.

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