Going crazy over umask in Ubuntu!!!!!!

The battleground for flame wars, off-topic derailments and spurious madness.
Post Reply
barbaz
Senior Member
Posts: 10841
Joined: Sat Aug 03, 2013 5:45 pm

Going crazy over umask in Ubuntu!!!!!!

Post by barbaz »

Been wondering why my Ubuntu system had switched to making new files and directories group-writable by default for quite a while now. (I swear it didn't do this when I first installed.)
The issue was occuring also in my VM, so wondered if it's something I did?

Nope.

Some searching indicated that this is controlled by umask. Looking in ~/.profile:

Code: Select all

# the default umask is set in /etc/profile; for setting the umask
# for ssh logins, install and configure the libpam-umask package.
#umask 022
/etc/profile:

Code: Select all

# The default umask is now handled by pam_umask.
# See pam_umask(8) and /etc/login.defs.
/etc/login.defs:

Code: Select all

UMASK		022
However:

Code: Select all

$ umask
0002
Wait, what the heck??? :shock:

Looking more at login.defs:

Code: Select all

# UMASK is the default umask value for pam_umask and is used by
# useradd and newusers to set the mode of the new home directories.
# 022 is the "historical" value in Debian for UMASK
# 027, or even 077, could be considered better for privacy
# There is no One True Answer here : each sysadmin must make up his/her
# mind.
#
# If USERGROUPS_ENAB is set to "yes", that will modify this UMASK default value
# for private user groups, i. e. the uid is the same as gid, and username is
# the same as the primary group name: for these, the user permissions will be
# used as group permissions, e. g. 022 will become 002.
...

Code: Select all

#
# Enable setting of the umask group bits to be the same as owner bits
# (examples: 022 -> 002, 077 -> 007) for non-root users, if the uid is
# the same as gid, and username is the same as the primary group name.
#
# If set to yes, userdel will remove the user´s group if it contains no
# more members, and useradd will create by default a group with the name
# of the user.
#
USERGROUPS_ENAB yes
Ah, so that's the cause. Why they would overload that setting like that I have no idea?

So, because we want to keep the useradd and userdel behavior - and we probably want system defaults for other accounts - the fix is to uncomment the umask line in ~/.profile, then log out and log back in.

Hope this saves someone some significant headaches. Too late for me though, I've now got craploads of files in home folder and a few other places (such as /srv) that are unnecessarily group-writable, and given my method of backups, a mass-chmod may not be practical. Oh well, at least chgrp requires root privileges, so this shouldn't matter for me at least for now. Image
*Always* check the changelogs BEFORE updating that important software!
-
Post Reply