6

When I login anew my umask is 002. At least for a while. Then at some point, and I'm not sure when, it reverts to 000. This is very inconvenient and I'm now constantly living in fear of dropping files and folders with strange permissions across my home directory.

The reversion to 000 can happen after minutes of use, or after days. A few weeks after I first installed ubuntu it happened quite a lot, then it cooled down, and just in the last few days this issue has reared its ugly head again.

I can set it back to 002 with $ umask 002 but this only works for the current shell (as expected).

Some more information:

  • The tty at ctrl-alt-f2 has a umask of 002 even when my f7 login is at 000
  • /etc/profile says that umask is now handled by pam_umask
  • /etc/login.defs has UMASK 022 and USERGROUPS_ENAB yes

I'm running Ubuntu 13.10 with XMonad and (oh-my-)zsh.

In case this is useful, here's my /etc/fstab

# <file system> <mount point>   <type>  <options>       <dump>  <pass>                                    
# / was on /dev/sdb8 during installation                                                                  
UUID=96f989e0-ee94-4bff-9663-3fa479a83ad4 /               ext4    errors=remount-ro 0       1
# /boot/efi was on /dev/sdb1 during installation                                                          
UUID=7682-B8AD  /boot/efi       vfat    defaults        0       1
# swap was on /dev/sdb7 during installation                                                               
UUID=0d7d57af-9a31-481e-9da4-1032c94f57e9 none            swap    sw              0       0

Here is an abridged version of my crontab from crontab -l

* * * * * cd /home/miles/code/Checkin/ && ./node_modules/.bin/coffee ./client.coffee -n attercop -h secret1.com -p 8888
* * * * * cd /home/miles/code/Checkin/ && ./node_modules/.bin/coffee ./client.coffee -n attercop -h secret2.com -p 8888

client.coffee is just a script that sends an http request.

And my root crontab from sudo crontab -l reports no crontab for root

Miles
  • 180
  • 9
  • That is strange. Are you setting a umask value when mounting your $HOME? Check /etc/fstab. – terdon Mar 19 '14 at 01:18
  • My $HOME is on the same partition as / and I'm not setting it in fstab. I've edited my fstab into my question for reference. – Miles Mar 19 '14 at 01:31
  • What do you mean by “reverts to 000”? In what program do you observe that? If you open a terminal and run a shell, does the umask change inside that shell? – Gilles 'SO- stop being evil' Mar 19 '14 at 01:36
  • What is the output of crontab -l and sudo crontab -l. – Braiam Mar 19 '14 at 01:37
  • 1
    You could get an idea of which processes are changing the umask and when with an auditd rule: sudo auditctl -A auditctl exit,always -S umask and look in /var/log/kern.log for audit logs. – Gilles 'SO- stop being evil' Mar 19 '14 at 01:38
  • @Braiam A crontab wouldn't affect running processes (unless via ptrace, which would be extremely weird). – Gilles 'SO- stop being evil' Mar 19 '14 at 01:39
  • @Gilles I observe it in the terminal. I usually observe it by running commands which happen to create files/dirs like ./site build and am surprised when those dirs have weird permissions. Then I type umask and the result is 000 (when the issue has happened, I just logged out and in so it's 002 for now.) – Miles Mar 19 '14 at 01:58
  • @Braiam I have edited my crontab into the question. – Miles Mar 19 '14 at 01:58
  • @Gilles I don't have auditd, should I install it from the autitd package? I have 4 possibly relevant lines in /var/log/kern.log which all say setup_percpu: NR_CPUS:256 nr_cpumask_bits:256 nr_cpu_ids:8 nr_node_ids:1 – Miles Mar 19 '14 at 02:03
  • 1
    Invoking a new shell like so: bash -x -l -i -c 'exit' 2>&1 | grep umaskand look for any errant umask's coming from a configuration file. – slm Mar 19 '14 at 02:13
  • @slm I doubt that would work since he use zsh. Well, it does work, but he has to be pending that he first has to run without the grep command or it could collide with the oh-my-zsh update script. – Braiam Mar 19 '14 at 02:19
  • 1
    @Braiam - something similar could be done with zsh. zsh -x -l -i -c 'exit' 2>&1 | grep umask. – slm Mar 19 '14 at 02:43
  • @Miles Yes, you would install the auditd package. But that's probably not necessary: given that you're observing this in zsh, the most likely explanation by far is that you have a stray call to umask somewhere in your zsh configuration, and you'll find it by looking through your .zshrc and other zsh files. – Gilles 'SO- stop being evil' Mar 19 '14 at 03:31
  • Aha! Thank you for all of your gracious help. I have found the issue and will post an answer below. – Miles Mar 22 '14 at 23:30

1 Answers1

2

The issue for me was caused by a Sublime Text 3 plugin called Terminal, which is used to launch terminals from sublime files. When Terminal launched the first and only window of gnome-terminal, then it inherited the umask of 000 from sublime.

In the hopes that this answer can be useful to those who are not having the same problem as me, I will reiterate some suggestions for how to attack this problem, garnered from the comments above:

  • Look through your rc files (.bashrc, .zshrc) to see if there are errant umask calls.
  • If you're using bash, try bash -x -l -i -c 'exit' 2>&1 | grep umask to find call to umask from your rc files.
  • If you're using zsh, try zsh -x -l -i -c 'exit' 2>&1 | grep umask to find calls to umask from your rc files.
  • Check whether you are setting a umask value when mounting $HOME. Look in /etc/fstab
  • Check whether there is anything strange running in cron that could change your umask. crontab -l and sudo crontab -l.
  • Perhaps try using audit to find the source of mysterious umask changes. sudo auditctl -A auditctl exit,always -S umask and look in /var/log/kern.log
Miles
  • 180
  • 9
  • Since bash -x -l -i -c 'exit' 2>&1 | grep umask does not output the filename, using grep -5 umask leaves some additional context lines which can help pinpoint the file. – BlakBat Jan 15 '16 at 12:05