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?
“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 alsomattdm. 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.
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.