Is there an better way to set the umask for gnome launched applications?

F38, Linux 6.4.9-200.fc38.x86_64, Wayland, Gnome 44.3
Though applies to all earlier versions going back to at least F33

Currently all applications run from the gnome menus (emacs, firefox, etc.) have a umask of 022 thus making all user files world readable, and the user is given no choice about this, because the umask in .profile, .bashrc, login are ignored.

(Fedora Linux permissions for created home directories prevent users from looking at each others files at the /home level. This prevents users from sharing files which might or might not be a good thing. Other Linux versions do not do this. Also, sometimes home is mounted from another volume.)

In Parot Linux they are using lightDM, and it reads the umask from .profile. I tried that but it does not work for F38/Wayland/Gnome.

On Fedora since F33, to set a different umask I add:
session optional pam_umask.so
to /etc/pam.d/login and to /etc/pam.d/systemd-user. Then I set the UMASK in login.defs. I have to create the file /etc/pam.d/systemd-user as it is not there on a fresh install.

Of course a user can not do that, so users get the default umask I set, which is not so permissive. This is not so bad, as chmod can be used if the user wants a file to be world readable, etc.

Is there an easier/better way to set the default umask for gnome sessions on F38?

Additional note, adding the ‘session optional pam umask.so’ line to the two files mentinoed above caused the audio devices to disappear (perhaps only from virtual machines), so not only is it lengthy, it breaks things. Gregory’s solution checked below, works without affecting audio devices.

I found this in the systemd.exec man page:

… In order to change the per-user mask for all user services, consider setting the UMask= setting of the user’s user@.service system service instance. …

So I guess they are recommending that you create a /etc/systemd/system/user@.service.d/override.conf file containing the following.

[Service]
UMask=0077

I’ve never tried it.

On my system the umask is 0022 and that is the default. It is set in /etc/bashrc. Remember that the execute bit is never set by default on files, only on directories so files are created by default with 644 permissions while directories are created with 755 when umask of 0022 is in effect.

However, there is another part that works for that.
The permissions of my users home directory are 0700 and that means that no one except the user can even see what is in that directory or below it. Thus 755 as the permissions for all directories and 644 for all files created by default in and under my users home directory are still protected from all other users except root.

Again, I have not tried this, but if you really want the user’s umask setting in their ~/bash_profile to affect all processes in the user’s session, it might be possible to hack something together that would do that. I’m thinking of something along the following lines in /etc/systemd/system/user@.service.d/override.conf.

[Service]
ExecStart=
ExecStart=/bin/sh -c 'source <(grep -m 1 -o "umask\s*[0-7]\{3,4\}" ~/.bash_profile); exec /usr/lib/systemd/systemd --user'

I haven’t tested the above script. But I think something along those lines might work as a hack to let the user specify their own umask in their ~/.bash_profile file and have it affect their entire GNOME session. (But be careful with the above script. I think it has the potential to lock you out of your system if it doesn’t work correctly.)

There might be better ways. Especially if, e.g., you are using something like an LDAP database for the user information and you can set the permissions so the users can modify their own GECOS fields (pam_umask claims it will read umask settings from GECOS fields).

Jeff, gnome does not pay attention to the value in /etc/bashrc. It is easy to show this, change that value, then launch an application from gnome, and you will see it is still world readable.

For one to claim this they must show exactly what they have done (step by step and including commands) so others may test and see if this is fact or if something has been changed that overrides the default config – including SELinux.

In my experience nothing under any users home directory is world readable without changing permissions on the /home/USER/ directory. Over 20 years experience with Linux backs me up in that.

Note that as long as the app is launched by that user they will have access to anything that user would be able to access from a command line terminal. Most apps run as the user who launched the app. If you have 2 different users defined on that system and each has some data in their home directory structure then this would be a test of what you claim.

  1. log in as one of the users and attempt to access something under the other users directory tree (either cli or gui). If permissions are configured as default this should not be possible.

Please provide an example with details.
The umask assigned when logging in from the gui may be changed in /etc/bashrc at any time. It will not have any effect until the user logs out then back in.

I can set the default umask in the file /etc/login.defs, and it works in xfce. I also tried if it also worked in a Gnome session, and it did not. Even after reboot.

Of course wiht the default setting of the user’s home directory to drwx------ only the user can access anything in that directory or below it.

Directions:

  1. set your umask in .bashrc. For grins, also add it to .profile, also edit /etc/bashrc and put it there if you want. Put it anywhere you think it is being read from.
umask 007

reboot (this will make sure that systemd, gdm, and the gang have had a chance to read your mask)

  1. go to activities in gnome and launch your favorite editor, in my case emacs.

  2. in that editor make a new file and save it. I have called that file ‘afile’

  3. pull up a shell, run ls

[user@fedora ~]$ ls -l
total 4
-rw-r--r--. 1 user user  3 Aug 15 18:07 afile

note file permissions show in the first colum, and they are orgnized in groups of threes:
rwx (user) rwx (group) rwx (world)

So for anyone who has the inode for the created file, they will find it is readable and writable by the user. It is readable by group. And it is readable by all users.

Conclusion: gnome ignored your umask.

In my experience nothing under any users home directory is world readable without changing permissions on the /home/USER/ directory. I have over 20 years experience with Linux to back me up in that.

I wrote asking about umask and file permissions. File permissions and umasks are a separate issues from that of how a user gets the file inode.

You make the claim here that files can not be accessed by other users because they are in a directory tree, and to get to any file you point out that it must be accessed by file path that goes through the Fedora home directory, and those do not give other users read or execute privleges - so other users will never be able to access the files in the first place. Thus the file permissions are moot, so world read is not really world read.

→ If this is the case, then it does not matter that file permission have world read, so why set world read in the first place?

→ So Fedora has deprecated Unix permissions? Users are not to have permission masks anymore? But only when they use a GUI? (An what a mess, when a different umask is put in .profile, emacs launched from a shell gives different permissions than when launched from the menus. Are you saying that this the new ‘normal’?)

As I mentioned in the original question, home is sometimes mounted, and other Linux versions do not make home directories group and other unreadable. Given your expereience, you might have noticed that Solaris, and Sys V, Berkely and other Linux distributions do not do this, as examples.

Anyway, my question was about setting the umask. I didn’t come here to debate the wisdom of leaving files world readable ‘because they can’t be gotten to’, or not. Though it is an interesting question. It would be interesting to know if the kernel or the file system guarantee that a file can not be opened if any directory along the path to that file does not grant execute or read. That begs questions about links and mounts, and what happens when changes are made. Do you have a reference to this fact? I would like to read it.

@glb provided some interesting suggestions, and I will try those. Thanks Jeff.

I can set the default umask in the file /etc/login.defs, and it works in xfce. I also tried if it also worked in a Gnome session, and it did not. Even after reboot.

Interesting about xfce, maybe we just use that. As I noted lightdm will take it from the user’s .profile, which is even better, as then it can vary from user to user.

Gnome uses systemd to launch processes. If I add the pam module lines mentioned in the original post, then the umask will come from login.defs. However I discovered today that if I add pam_umask.so to the pam.d files, and spin it up as a virtual machine, there are no audio devices. So apparently it is affecting something else that has a user processes that needs world readable files. I am curious to find out of @glb solution will run into this same problem or not.

It works! … and unlike what I was doing, the audio devices work when this is spun up on a VM.

The other solution you suggest below is brilliant, and really close to the ultimate solution. It should have a script that reads the .profile, upon finding a mask uses it, and upon not finding one sets the default, say 0077 or 0027. I think I understand that line well enough to give a shot at modifying it, probably while spinning up machines that do not boot…

If you also set the normal UMask=... to what you want the default to be, the ExecStart= line should override that default if it finds a “umask …” line in ~/.profile.

One thing to be aware of with that hack is that it is ignoring all other content and any sort of logic that might exist in the .profile file. So, e.g., it would still find and use something like the following.

if false; then
  umask 0022
fi

You can set the umask for the user instance of systemd like this

sudo systemctl edit user@.service

and then add the lines

[Service]
UMask=027

See man systemd.exec and search for the string “UMask=”.

You don’t want to create a new user@.service file under /etc/systemd/system. Instead, you want to create an “override.conf” drop-in snippet under /etc/systemd/system/user@.service.d.

If you create a user@.service file with just that content, it will completely undo all the other settings that are defined in /usr/lib/systemd/system/user@.service (and probably lock you out of your system).

I fixed the mistake. systemctl edit will create that override file and also reload the configuration.

1 Like

Good point about the logic missing. It is not possible to evaluate .profile because it might use variables that are not yet set.

There could be a .gdm file in the home directory that does not allow logic, just variables and values. Then the skeleton .profile could pull that in. Perhaps too many layers.

It would be natural if the umask command inside of .profile, and only inside of .profile, could communicate with systemd to change the umask it uses for user exec. It could be called something other than umask. Though, this is beyond my current understanding of systemd.

The checked solution gets the job done for now.