How to set `umask` for the entire gnome session

gnome3umask

Using Gnome 3.18. I share files between other family members, but the default umask on my distro (archlinux) is 0022. So every file/directory created is not writable for our common group.

I tried to put umask 0002 in /etc/profile but the gnome session is still using 0022. It's working for a login bash shell, though.

I also tried to add this line in /etc/pam.d/system-auth:

session required pam_umask.so umask=0002

It has the same effect as the one in /etc/profile.
I tried

If I change the umask manually in a gnome-terminal shell, then I launch an application from it, say gedit, then the files created by it have the wanted permissions. If I launch gedit from the gnome menus, it doesn't. So my matter is really to set the umask for the gnome session, and I can't find where to do it.

EDIT (to answer Gilles' comment):
I'm using gdm 3.18 as the DM.
I also tried to add the pam_umask line into /etc/pam.d/gdm-launch-environment. All other gdm-* files contains includes of session from the system-auth file, so they should not need more. It doesn't change anything.

/etc/login.defs contains UMASK 077 but also USERGROUPS_ENAB yes which should set the umask to either 0077 or 0007 for users whose primary group is the username.

The only file that contains 022 for umask in /etc is /etc/profile but that was my first try.

As for /etc/Xsession.d, I don't have this directory. Besides, as wayland is now the default display server, I'm not sure the umask should be set as part of X initialisation, even if I'm still using it myself.

Best Answer

Some Gnome applications are launched by systemd --user, in which case umask is set by systemd to 0022 regardless of the configured value for pam_umask. I am not aware of any workarounds, but I opened an issue on systemd github issue tracker. This issue is also reported on Gnome bugzilla.

Umask set using pam_umask is working as expected for applications which are not launched by systemd --user.

One workaround is suggested on Ubuntu bugzilla to place systemd service overrides to all affected applications.

Update: pam_umask should work as expected for systemd version 246 and newer. Newer distribution releases should ship with a version where the bug is fixed.

To investigate this yourself

You can list the processes running on your system in a tree format (parent/child processes) using:

pstree -Tapu

Find PIDs for: (1) your session's instance of systemd --user; (2) an application launched by it, such as gedit, which will show as child process to systemd --user; and (3) a process in your session not launched by systemd --user.

Compare umasks reported in procfs:

grep Umask /proc/<pid>/status

systemd --user itself (1) and processes not launched by it (3) should have the correct umask which was set by pam_umask. Processes launched by systemd --user (2) will have umask of 0022.

Related Question