14

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.

Christophe Drevet
  • 4,157
  • What display manager do you use? (That's the program where you enter your username and password.) Gdm, lightdm, slim, xdm, kdm, …? Depending on how Arch and your DM are set up, try adding a file in /etc/Xsession.d, or a different file in /etc/pam.d (I'm assuming you want to set this system-wide). Or maybe /etc/login.defs. – Gilles 'SO- stop being evil' Jan 10 '16 at 21:56
  • The two answers are valid for tty or ssh logins, and they are basically the same one, really (using pam_umask). They don't work with my gnome session. So I can't give the bounty to anyone. I don't know if this is specific to gnome on Xorg on archlinux. I'll test with other distributions when I have some time. – Christophe Drevet Jan 20 '16 at 10:47
  • 1
    There is a similar thread on the archlinux forum treating the issue: https://bbs.archlinux.org/viewtopic.php?id=207753 Seems like a bug in gdm... –  Jan 27 '16 at 07:07
  • I ended up using ACLs, which is a much better way of controlling permissions. No need to change the default safer permissions mask. – Christophe Drevet Jan 19 '18 at 13:45

10 Answers10

7

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.

sebasth
  • 14,872
3

The problem is that mentioned by Sebasth. I tried many things, but then I found a workaround which consists in overwriting the (per-user) UMask of dbus:

$ systemctl --user edit dbus

In the file that gets opened, just write:

[Service]
UMask=002 # This is the umask I want to use

The file gets saved in .config/systemd/user/dbus.service.d/override.conf and overrides the dbus default umask, which I presume is inherited from systemd --user, since dbus is launched by it. Just logout and login again and gnome applications should use the specified umask. Just a workaround, but it works for me.

Jeff Schaller
  • 67,283
  • 35
  • 116
  • 255
egdoc
  • 31
2

To set default umask system-wide you will have to enable it in first place, which pretty well explained here:

http://manpages.debian.org/cgi-bin/man.cgi?query=pam_umask&sektion=8

The above link is for debian and ubuntu but the same for all other linux systems.

To enable it umask (which maybe already in place) you need to add a line to /etc/pam.d/common-session:

session optional pam_umask.so

Once enabled you can then set it up in:

/etc/login.defs

I see you already found this file so all you need to do is to set:

# The permission mask is initialized to this value. If not specified,
# the permission mask will be initialized to 022.
UMASK           077

And set it UMASK to 0002 or whatever you'd like to.

This will set default value system-wide, which means all users will have pick up the umask from there unless they don't specifically set otherwise in their .profile or .bashrc

Christophe Drevet
  • 4,157
ostendali
  • 187
  • Thank you for your answer. I'll have to try that. I'm not that optimistic because I already tried this PAM module with an inline parameter "umask=0002" and it didn't work (for Gnome, it did work for other login shells, though). I'll try your suggestion. – Christophe Drevet Jan 14 '16 at 20:30
  • you tried pam module for system-auth not common-auth:-) – ostendali Jan 15 '16 at 09:34
  • 5
    It's just a matter of distribution choice of file names. I know debian uses common-* for common settings. Arch, as RedHat, uses a system-auth file for this. Anyway, I tried your suggestion of adding session optional pam_umask.so and and UMASK 002 into /etc/login.defs As I expected, and as with pam_umask.so umask=0002, it worked for a tty login session (or through SSH) but Gnome set a 0022 umask as always. Gnome must use an internal umask setting, or archlinux is using one… I'll try another distribution to see if the issue arises too. – Christophe Drevet Jan 18 '16 at 20:18
  • This seems to be the cleanest way, even the distribution I am using has already prepared common-session accordingly including a nice comment. – doak Oct 24 '23 at 13:14
2

Instead changing the umask you could use the usergroups option for pam_umask, with this user and group has the same permissions, as the classical unix way to share folders.

# /etc/pam.d/login or
# /etc/pam.d/common-session or system-auth
session optional pam_umask.so usergroups
xae
  • 2,021
  • 1
    If the user is not root and the username is the same as primary group name, the umask group bits are set to be the same as owner bits (examples: 022 -> 002, 077 -> 007). – Christophe Drevet Jan 19 '16 at 08:37
  • I use the primary group as the sharing group. With user groups, files will be created with this user group by default, and not editable by other users. – Christophe Drevet Jan 19 '16 at 08:43
  • 1
    I see a way, though: I can use user groups, and a common secondary group, and then, on the shared tree, add a "set group" bit to force this common group on all created files and folders. Anyway, I'll try on my PC later. I'm not sure gnome will care about that anyway, because it always take 0022 as a umask, no matter what is working for tty sessions. – Christophe Drevet Jan 19 '16 at 08:43
1

EDIT: To get systemd to set the gnome session's umask, I created a umask.conf file under /etc/systemd/system/display-manager.service.d/ with the following lines:


[Service]
UMask=0002

After rebooting the machine, this now allows all processes under user.slice to conform to the umask you would like. Logging out was not sufficient for the changes to take place so i would advise to reboot your machine before performing the tests on process umasks.

 Additional Info:

  • OS: CentOS7.4
  • DE: Gnome3
jamalm
  • 199
  • 4
  • 14
  • 3
    If it's working, then a file like /etc/systemd/system/gdm.service.d/umask.conf containing only [Service]\nUMask=0002 should be enough. – Christophe Drevet Jan 19 '18 at 13:42
  • And indeed it does! just tested it there. my /etc/systemd/system/ folder contains a symlink to gdm.service so i created a display-manager.service.d/umask.conf and added the line, this worked perfect, going to update the answer to include it.Thank you @ChristopheDrevet-Droguet – jamalm Jan 19 '18 at 13:52
  • No apparent effect under debian Bullseye – Olivier Cailloux Sep 23 '21 at 09:05
0

For the login session: add umask 0002 to your $HOME/.profile (or /etc/profile).

For the Gnome session: add umask 0002 to your $HOME/.gnomerc

Stephen Harris
  • 44,540
ctruta
  • 9
0

Just wanted to add that the pam_umask manpages provide some pretty good info to help you figure out where your umask is coming from. Specifically:

pam_umask is a PAM module to set the file mode creation mask of the current environment. The umask affects the default permissions assigned to newly created files.

The PAM module tries to get the umask value from the following places in the following order:

·   umask= argument
·   umask= entry of the users GECOS field
·   pri= entry of the users GECOS field
·   ulimit= entry of the users GECOS field
·   UMASK= entry from /etc/default/login
·   UMASK entry from /etc/login.defs

As somebody has stated, you should set this up in the common-session file in the directory /etc/pam.d.

Do note that logins which do not use pam (such as those that use getty or login will have their umask set via login.defs.

Stephen Rauch
  • 4,239
Charles D Pantoga
  • 101
  • 4
0

On a install of Fedora 29 with Gnome I found that, programs launched from the Gnome launcher left files other readable, 0022. Pam apparently defers to /etc/login.defs as noted above. However, editing the mask there, 0077, did not change Gnome's behavior. I also had to edit /etc/profile, and to /etc/bashrc - both of which were setting it back to 0022.

It would be nice if Fedora had one place for this, but the entries in /etc/profile and /etc/bashrc set the mask differently for users with IDs above or below 200, so it seems that one mask does not fit all.

Though this is a fix for now, the problem isn't completely solved, as the gnome user still has no way of setting his or her own umask as it is applied to applications that run from the gnome launcher. Seems Gnome should have a config option for that umask. (Maybe it does, but I didn't find it.)

Michael Prokopec
  • 2,220
0

I have the workaround at least on Fedora 31:

sudo vi /etc/profile.d/umask.sh
umask <your_umask>

sudo vi /etc/login.defs
UMASK <your_umask>

sudo vi /usr/local/bin/systemd-user
/usr/lib/systemd/systemd --user

sudo chmod a+x /usr/local/bin/systemd-user

sudo vi /usr/lib/systemd/system/user@.service
ExecStart=-/usr/local/bin/systemd-user
Paulo Tomé
  • 3,782
Charles
  • 1
0

Tested on Ubuntu 20.04 & GNOME 3.36.8

To have systemd --user apps set to a specific umask

in /etc/login.defs change UMASK and USERGROUPS_ENAB according to your needs.

For example:

UMASK 0027 with USERGROUPS_ENAB yes - leads to systemd --user apps using umask 0007

UMASK 0027 with USERGROUPS_ENAB no - leads to systemd --user apps using umask 0027

NOTE: After every /etc/login.defs change a reboot is required

NOTE: If you set USERGROUPS_ENAB no use useradd -U when you create new users, if you want to create a group with the same name as the user, and add the user to this group, otherwise without -U a useradd will set the primary group of the new user to the value specified by the GROUP variable in /etc/default/useradd, or 100 by default: gid=100(users) groups=100(users).

Grandeto
  • 1