(In reply to Reuben Thomas from comment #0)
> I set my umask in my .profile to 0027.
[...]
> Both are configured not to start a login shell.

There's the solution: .profile is only sourced for login shells (at least on debian derived distributions).

Thanks for your reply. I am sorry, I tried very hard to be clear, but obviously failed.

.profile is run at login, and sets various environment variables. These are all correctly set in gnome-terminal and xterm.

As I said previously, neither gnome-terminal nor xterm is configured to start a login shell. Yet in xterm both the environment variables (which are only set in .profile) and umask are correctly set, whereas in gnome-terminal only the environment variables are set correctly, and the umask has been changed to a different value.

Just to confirm: /etc/gdm/Xsession on my Ubuntu system contains the lines:

# First read /etc/profile and .profile
for file in /etc/profile "$HOME/.profile"; do
  if [ -f "$file" ]; then
    source_with_error_check "$file"
  fi
done

Some additional information, for the sake of clarity: umask(2) says:

A child process created via fork(2) inherits its parent's umask.  The umask is left unchanged by execve(2).

I am assuming therefore that my umask having been set, by my .profile, by /etc/gdm/Xsession, that the same process will (eventually) start gnome-terminal-server (via gnome-terminal), and that therefore the umask I set should be inherited (as occurs with xterm).

This is why I believe that something has changed the umask.

Neither vte's nor gnome-terminal's code has any umask() calls.

If I start gnome-terminal (no previous instance running) from my xterm with a weird one-off umask manually set in that xterm, my umask gets reset to my preferred value in g-t. If I start the server manually and then a client(*) then that weird umask is preserved.

(*)The two commands shown at https://wiki.gnome.org/Apps/Terminal/Debugging, without the gdb bits.

So it must have something to do with the dbus activation, it's probably dbus (or a closely related component) that decides on the umask.

(Remotely reminds me of https://bugs.launchpad.net/terminator/+bug/1646034.)

Just for the record: Could you please check the umask of your gnome-terminal-server process?

grep Umask /proc/$(pidof gnome-terminal-server)/status

Thanks, Egmont. I'd already grepped through gnome-terminal, but I hadn't gone deeper (e.g. I didn't check glib for GApplication, though I read the docs and they don't mention changing the umask).

I can reproduce the preservation of my session umask if I run gnome-terminal-server with a custom app-id.

$ grep Umask /proc/$(pidof gnome-terminal-server)/status
$ echo $?
1

A quick cat of the status file confirms that there's no Umask line (or similar).

Lack of the Umask line tells us nothing. Unfortunately it seems like a brand new feature, not yet available on your Ubuntu 16.04. (I'm on Ubuntu 16.10 and it's already there.) See e.g. http://unix.stackexchange.com/questions/258284/current-umask-of-a-process-with-pid for another possible method.

The answer is, the umask of that process is 0002. Thanks very much for digging out a way for me to get it.

(In reply to Reuben Thomas from comment #4)
> I am assuming therefore that my umask having been set, by my .profile, by
> /etc/gdm/Xsession, that the same process will (eventually) start
> gnome-terminal-server (via gnome-terminal), and that therefore the umask I
> set should be inherited (as occurs with xterm).

No, Xsession isn't starting g-t-server. gnome-terminal-server is started by systemd or (on older systems like yours) by the dbus demon, and thus inherits that one's umask (unless they change it before the exec).

Christian, thanks for the clarification.

So, where is the bug?

I think it is clear there *is* a bug: I am setting the umask in my .profile, which is loaded into the session, and it's a reasonable expectation that it be respected by all processes started in that session.

As you observe, gnome-terminal-server is started in different ways on different systems; I don't think it's reasonable to expect the user to understand all of these, let alone duplicate the umask settings so that their session will work with dbus/systemd/whatever.

Presumably this problem can affect other processes, not just gnome-terminal-server.

I found this bug for dbus: https://bugs.freedesktop.org/show_bug.cgi?id=18446

And indeed in my (default) Ubuntu 16.04 configuration /etc/dbus-1/session.conf, "keep_umask" is set.

This suggests that either dbus is not starting g-t-s on my system, or the problem is elsewhere.

I notice that I do have a /lib/systemd/systemd --user process.

I can't find any mention of UMask in the systemd configuration. systemd.exec(5) says that the default value is 0022, so no explanation of how it's ending up as 0002 for me.

As for user session configuration, of all the possible locations listed in systemd-user.conf(5), only /etc/system.d/user.conf exists on my system, and its contents is entirely commented out (and does not mention UMask anyway).

I did some more investigation on how to set the umask for the user session in systemd, but I couldn't work out how to do it. I tried adding

[Service]
UMask=0027

to ~/.config/systemd/user.conf, or to ~/.config/systemd/user/umask.conf, but with no effect. Searching online I couldn't find anything about precisely setting the umask of the user session. (In any case, this would only be a work-around, as the setting would still be duplicated from my .profile; what is really needed is a similar setting to that available in dbus.)

Try using pstree to find which process is the parent of gnome-terminal-server, and then look what that one's umask is?

Thanks again.

Using pstree -H to highlight the parent, I've confirmed it's the root systemd (PID 1).

Confirmed with pstree --show-parents: it's PID 1.

(I presume trying to attach gdb to PID 1 to find out the umask is not a good idea.)

You're reading this wrong, it's not the PID1 systemd, it's the user systemd. (Unless you're logging in to GNOME as root? That's completely unsupported.)

Sorry if I've misread something or done something wrong. Here's more detail:

$ whoami
rrt
$ id -u
1000
$ pidof gnome-terminal-server
26250
$ pstree -alp -H26250 -s 26250
systemd,1 splash
  └─gnome-terminal-,26250
      ├─bash,5594
      │   └─lua,14120 /home/rrt/.local/lib/luarocks/rocks-5.3/cw/2.0.4-1/bin/cw /home/rrt/.local/lib/luarocks/rocks-5.3/cw/2.0.4-1/libexec/cw/pstree -alp -H26250 -s 26250
      │       └─pstree,14122 -alp -H26250 -s 26250
      ├─bash,8014
      ├─bash,26254
      ├─{dconf worker},26253
      ├─{gdbus},26252
      └─{gmain},26251

The highlighted lines in the above are the first one and the second, which seems to me to indicate that the direct parent of gnome-terminal-[server] is systemd (PID 1).

I'm not logged in as root, I'm logged in as a user created in the normal way with the Ubuntu GNOME installer.

One extra piece of information: it seems that on my system gnome-terminal is indeed started by dbus:

$ cat /usr/share/dbus-1/services/org.gnome.Terminal.service 
[D-BUS Service]
Name=org.gnome.Terminal
Exec=/usr/lib/gnome-terminal/gnome-terminal-server
$ locate gnome-terminal|grep systemd
$ echo $?
1

I shall try therefore investigating dbus instead. However, I understand that more recent versions of GNOME start gnome-terminal via systemd, so that is the route that a fix for this bug needs to address.

I cannot understand what is going wrong on my system: dbus's session.conf has the keep_umask option, so why when it starts gnome-terminal that does not preserve the umask I don't know.

However, I discovered that --disable-factory is an Ubuntu customization and still available on my system, so I have simply written a wrapper for gnome-terminal to use that. Nevertheless, starting a new gnome-terminal-server for each gnome-terminal is obviously ugly and wasteful, so if there's anything else I can do to help fix this bug, do let me know.

So we've established (comment 9) that gnome-terminal-server's umask is set to the same value as the one as bash/etc inside gnome-terminal, so there's no bug in gnome-terminal here. How that umask comes to be set to the value it has is a problem elsewhere. Try your distribution's support forums or bug tracker.

I will do.

However, there is clearly a weakness in gnome-terminal's design here. With a traditional single-process terminal emulator, such as xterm, there is no possibility of this problem arising: the program is started within the desktop session, inheriting whatever umask (and other settings) are configured in that session.

Further, this problem is not limited to gnome-terminal: other client-server GNOME programs are likely to have the same problem. Looking in my system under /usr/share/dbus-1/services, I see quite a few.

The problem may be due to configuration outside GNOME itself, but it's a choice made by the design of GNOME, hence it's an issue for which GNOME should take responsibility. As a GNOME user, I shouldn't be burdened with understanding how underlying components of the system are set up and configured just in order to avoid this sort of problem, which is not just an inconvenience, but a security risk.

Hence, I'm reopening this issue as a placeholder until I can file an appropriate higher-level GNOME issue; I would appreciate some guidance on where such an issue should be filed.

Thanks again for your help.

This really isn't the right place to discuss this.

I don't know which kind of session you run; is it gnome-session as started by gdm? If so, I might move this over. If not, it's certainly NOTGNOME and best discussed with your distribution, not upstream.

I am running a default GNOME session from Ubuntu GNOME 16.04, which is indeed gnome-session started by gdm.

-> gnome-session for triage, although I'm not sure it's the right place either.

Thanks!

~/.profile will not be sourced before gnome-terminal-server is started if it's started by dbus-daemon or systemd --user.  My guess is if you did

$ systemctl --user edit dbus
[Service]
UMask=0027

$ systemctl --user edit gnome-terminal-server
[Service]
UMask=0027

one of the two would fix the problem.  Probably systemd should have a DefaultUMask= option for user.conf but I don't think it does. Can you file that on github?

Thanks; I tried those two commands and both give an error:

No files found for gnome-terminal-service.service.

(or "dbus.service" for the dbus variant). I guess this is because Ubuntu GNOME 16.04 is using dbus to launch gnome-terminal, not systemd?

Your suggestion of a DefaultUMask option for user.conf sounds as though it would fix the problem in the same way as the equivalent DBus option, but I think it should be raised by someone on the gnome-session team, because it needs to be documented as part of the requirements of gnome-session (otherwise, gnome-session has an undocumented reliance on a particular configuration of systemd simply to fix this bug). This also sounds like a rather fragile fix (because it relies on configuring an underlying component in a particular way). Is there a better way to do this?

For example, it's a surprise to me that systemd --user does not run in the scope of the user's .profile. Is there a reason for this? Can it be changed so that it does? This is presumably not just a matter of the umask, but more fundamentally of anything else set in the user's .profile (environment variables are certainly not respected at present, for example; what about ulimit parameters?). This is a fundamental (in the literal sense) breakage of the normal expectations of session login, and it requires a robust fix.

Reopening, since regardless of where the fix is located, it's a bug in GNOME.

there's nothing gnome-session can do really. it's not involved at all.  gnome-terminal requests a service provided by gnome-terminal-server.  dbus either activated gnome-terminal-server or farms off the task of activating gnome-terminal-server to systemd.  The easy, maybe good enough, solution would be for you to tick the "run a login shell" preference in gnome-terminal or set umask in ~/.bashrc instead.

Thanks, Ray.

I tried setting umask in ~/.bashrc before I settled on my current workaround of disabling gnome-terminal-server, which has the advantage of getting all the other settings from my .profile too. (Running a login shell does not work, because it imposes the extra burden of requiring .profile to be idempotent, which mine is not, nor is it a reasonable expectation.)

Clearly, neither is a good solution because a) it requires user intervention, and b) it only fixes gnome-terminal, not any of the other apps run through servers started outside the scope of the user's .profile.

Since you consider the bug outside the scope of gnome-session, please reassign it to the appropriate component, or file an appropriate upstream bug, and link it to this one.

In the mean time, it would also be good to have a *single* workaround that fixes *all* user settings (not just umask) for *all* apps (not just gnome-terminal). I've yet to see any suggestion that would do this.

Lot of thanks to Reuben Thomas for having discovered, reported and dug the issue.

'gnome-terminal' version 3.20.2-1ubuntu8 from 'Ubuntu 17.04' seems to have the same issue, which I have reported at https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1685754 :

$ GTS_PID=$(pidof gnome-terminal-server)

$ PARENT_PID=$(ps --no-header -o ppid $GTS_PID  |  sed -e 's/ //g')

$ ps n -fp $GTS_PID,$PARENT_PID
     UID   PID  PPID  C STIME TTY      STAT   TIME CMD
    1001  2551     1  0 avril27 ?      Ss     0:00 /lib/systemd/systemd --user
    1001  4812  2551  0 avril27 ?      Ssl    0:10 /usr/lib/gnome-terminal/gnome-terminal-server

$ grep -e Name -e Umask /proc/{$GTS_PID,$PARENT_PID}/status  |  sort
/proc/2551/status:Name:	systemd
/proc/2551/status:Umask:	0007
/proc/4812/status:Name:	gnome-terminal-
/proc/4812/status:Umask:	0022

$ cat /usr/share/dbus-1/services/org.gnome.Terminal.service
[D-BUS Service]
Name=org.gnome.Terminal
SystemdService=gnome-terminal-server.service
Exec=/usr/lib/gnome-terminal/gnome-terminal-server

This proves that 'gnome-terminal-server' has the wrong 0022 umask, although it is started by 'systemd' in user mode with the right 0007 umask.

This seems to point the bad 'umask=0022' hardcoding inside 'gnome-terminal-server' and/or inside the method defined by GNOME to start 'gnome-terminal-server' through the 'dbus' service.

Anyway, this bad 'umask=0022' hardcoding, which must be corrected, is somewhere inside GNOME.

Thanks to Seth Arnold for his advices to use the 'perf' or 'auditd' tools.

Inside the example '/var/log/audit/audit.log' which he provided, I do NOT find the 'umask' string.

So, I prefer to begin installing and using the 'perf' tool :

$ sudo  apt-get  install  linux-tools-generic

Close the graphical session.


Record 'umask' for a Gnome session without doing anything
---------------------------------------------------------

  Switch to a console (tty2), and login.

  $ sudo  perf  record  -ag  -e syscalls:sys_enter_umask

  Switch to the 'gdm' login screen.

  Open a Gnome session, then immediately close it.

  Switch to the console (tty2).

  Press Ctrl-C.
  ... (325 samples)

  $ sudo  perf  script  > gnome-umask.log


Record 'umask' for a Gnome session with a Gnome terminal
--------------------------------------------------------

  $ sudo  perf  record  -ag  -e syscalls:sys_enter_umask

  Switch to the 'gdm' login screen.

  Open a Gnome session.

  Inside the Gnome session, open a Gnome terminal with Ctrl-Alt-T.

  Close the Gnome terminal with Ctrl-D.

  Close the Gnome session.

  Switch to the console (tty2).

  Press (Ctrl C).
  ... (329 samples)

  $ sudo  perf  script  > gnome-umask-with-gnome-terminal.log


Additional traces triggered by Gnome terminal
---------------------------------------------
Following command eases the discovery of the additional traces :
$ diff  -I '[0-9]* *\[ *[0-9]* *\] *[0-9.]*'  gnome-umask.log  gnome-umask-with-gnome-terminal.log

> systemd-journal   360 [005] 10229.742513: syscalls:sys_enter_umask: mask: 0x0000003f
>                  f7907 __GI___umask (/lib/x86_64-linux-gnu/libc-2.24.so)
>                      0 [unknown] ([unknown])
> 
> systemd-journal   360 [005] 10229.742521: syscalls:sys_enter_umask: mask: 0x00000012
>                  f7907 __GI___umask (/lib/x86_64-linux-gnu/libc-2.24.so)
> 
> (l-server) 12464 [003] 10229.742634: syscalls:sys_enter_umask: mask: 0x00000012
>                  f7907 __GI___umask (/lib/x86_64-linux-gnu/libc-2.24.so)
>                  8f2af [unknown] (/lib/systemd/systemd)
> 
> bash 12472 [005] 10229.881381: syscalls:sys_enter_umask: mask: 0x00000007
>                  f7907 __GI___umask (/lib/x86_64-linux-gnu/libc-2.24.so)
>                1e0e1a8 [unknown] ([unknown])


Interpretation of the additional traces triggered by Gnome terminal
-------------------------------------------------------------------
The 'bash' trace logically comes from the 'umask 007' command in my '.bashrc' file.

Since 0022=0x12, the suspect for 'umask 022' hardcoding is '(l-server)'.

Again, gnome-terminal-server does *not* change your umask. In fact, it never calls umask(3p), as you can verify using 'git grep' on its source code.

The issue here, again, is simply that .profile isn't involved in how systemd --user sets up the umask. systemd has its own configuration mechanism for this, see https://www.freedesktop.org/software/systemd/man/systemd.exec.html#UMask= .

I suggest RESOLVED:INVALID for this bug.

Christian, thanks for your excellent summary.

Indeed, gnome-terminal is not at fault (and thanks for suggesting the bug be reassigned).

You've given a much better characterization of the bug than I have managed:

"The issue here is simply that .profile isn't involved in how systemd --user sets up the umask."

This is the bug that needs to be fixed: from a GNOME user's point of view, systemd is an implementation detail, which has now (unfortunately) become visible: a classic leaky abstraction.

So GNOME needs to be fixed so that the entire user session is always run in the scope of the user's .profile.

I would add once more that this is not just about the umask: environment variables, ulimit settings; in general, any and all environment settings that are normally respected should be preserved. I will retitle the bug to reflect this.

(In reply to Reuben Thomas from comment #36)
> This is the bug that needs to be fixed: from a GNOME user's point of view,
> systemd is an implementation detail, which has now (unfortunately) become
> visible: a classic leaky abstraction.
> 
> So GNOME needs to be fixed so that the entire user session is always run in
> the scope of the user's .profile.

That won't work, since the systemd --user instance will itself not see anything in .profile since it doesn't take its configuration from the environment, and thus still use its own default for umask, etc., when autostarting dbus services.

IMHO, the problem here is simply mismatched expectations: you expect that .profile is where you configure these things, but this isn't the case (anymore). The actual place to configure these is where systemd --user gets its defaults from. That's not a 'leaky abstraction', it's only a *change*.

(In reply to Christian Persch from comment #37)
> (In reply to Reuben Thomas from comment #36)
> > This is the bug that needs to be fixed: from a GNOME user's point of view,
> > systemd is an implementation detail, which has now (unfortunately) become
> > visible: a classic leaky abstraction.
> > 
> > So GNOME needs to be fixed so that the entire user session is always run in
> > the scope of the user's .profile.
> 
> That won't work, since the systemd --user instance will itself not see
> anything in .profile since it doesn't take its configuration from the
> environment, and thus still use its own default for umask, etc., when
> autostarting dbus services.

It doesn't make sense to say "this won't work". It needs to be made to work. GNOME has decided to use systemd as an optional component, which is fine, and a long-standing expected behaviour has been broken as a result. This needs fixing. How best to do this is of course a matter for GNOME developers; users are just concerned with observable results.

In this case, the observable result is that a de facto standard behaviour, namely that the user session runs in the scope of .profile, is broken.

You can see from the design of other desktops, PAM, ssh, dbus etc., all of which accommodate this expectation, that it is indeed a standard, even if it's not explicitly laid down in broad terms.

> IMHO, the problem here is simply mismatched expectations: you expect that
> .profile is where you configure these things, but this isn't the case
> (anymore). The actual place to configure these is where systemd --user gets
> its defaults from. That's not a 'leaky abstraction', it's only a *change*.

If this is an intentional change, then it should be discussed at a high level (please point to such discussion if I've missed it), documented in release notes etc., because it's a big and breaking change to traditional behaviour.

Further, in this case there should be a documented migration path which does not involve having to have duplicate settings. If users should use something other than .profile for setting environment variables, umask &c., that needs to be documented, and of course it should work in the other direction, that is, the user's settings should be transmitted appropriately to shells, console logins, other desktop environments etc.

Since I see no evidence that a change of this magnitude was intended (again, I'm happy to be corrected), I have assumed it is a bug. Many users will simply experience it as a bug (or series of bugs) whether it was intended or not.

In any case, putting a new mechanism in place will be a lot of work, and it might be easier simply to keep things backwards-compatible.

Environment variables
---------------------
For environment variables, it would be nice if GNOME considers 'systemd --user' as a login shell and runs it (with all its children) in the context of '.profile'.

UMASK
-----
-  'man pam_umask' clearly states that 'pam_umask' sets the user's umask according to the umask= entry in the user's GECOS field of '/etc/passwd'.
-  This works correctly for 'systemd --user' (the parent of 'gnome-terminal-server').
-  Users really expect that ALL children processes of 'systemd --user' simply inherit the umask value from their 'systemd --user' parent.
-  GNOME MUST RESPECT THAT.

Temporary workaround for umask
------------------------------
-  https://www.freedesktop.org/software/systemd/man/systemd.exec.html does mention the existence of an 'UMask=' option.
-  Is it possible to document in which section of which file this option has to be set ?

Is this bug related to this: https://bugzilla.gnome.org/show_bug.cgi?id=784113

In gnome 3.22, how do I set a default umask that gnome respects? So for example if I login to gnome thru GDM and then open gedit and create a document, the document has permissions 600 by default.

Where do I go within gnome (or debian) to configure this?

*** Bug 784113 has been marked as a duplicate of this bug. ***

@Christian Perse, do you know a workaround to get this working until this bug is fixed? What about Comment 39's "UMask=" option. Is there a config file where this can be inputted to see if it has any effect?

Is it currently impossible to change the environment's umask?

Now that the title of this issue is clearly focused on UMASK :

I confirm that this issue is a security issue, which must be corrected.

IMHO, the best fix would be that GNOME systematically uses the standard 'pam_umask' module.

Thank you in advance.

@Christian Perse, how can one set the default umask in Ubuntu Gnome 16.04+ or Debian Gnome 9?

Not being able to set a default umask is a huge omission to have plaguing Gnome for well over a year now. It's preventing me from using Gnome in said distros. This bug should be a much higher priority to fix--it makes the distro unusable as way too much work is involved to have to individually change every single file's umask upon creation of a file.

When is this going to be fixed or a way to change the default explained?

Hello,

That bug is not fixed in 17.10 !

For reference : https://forum.ubuntu-fr.org/viewtopic.php?pid=21823638#p21823638

tl;dr → umask is set at 002 in ~/.profile AND in /etc/login.defs
but new folders created through Nautilus ( or terminal ) don't grant write permission for group.
Unless if created in desktop folder ( why ? ).

That's a big problem in multi-users environment.

Other curiosity, I don't have that problem with i.e. Budgie 17.10 where setting umask at 002 in /etc/login.defs works as expected.

It's a real pain for managing machines with multi-users and shared folders.

What is the reliable way to set umask for files and folders created through *any* app's run at user level ?

With systemd version 237-3ubuntu7 from Ubuntu 18.04 beta 2 (Bionic), the issue is still the same.

fwiw, in fedora we're going to start adding pam_umask to the default pam configuration so admins can edit /etc/login.defs

Ray Strode, it sounds like a good news !

Does it mean pam_umask - as set by /etc/login.defs - has always been absent from Gnome environment ? How comes ?

nope you got it backwards. pam_umask is the library that reads login.defs, login.defs isnt what sets pam_umask.  this has nothing to do with the gnome environment itself, but the system level services that start gnome (and those same system things start programs unrelated to gnome). see comment 31

Ok... Thanks for explanation.

I've asked because I still can set umask globally, in Ubuntu 17.10 budgie, as I used to in previous Ubuntu versions. Probably because budgie does not make so much use of systemd (?)

I am fairly certain the bug is not (at least not completely) in any gnome project.  It appears to be in dbus.  In particular, dbus has two issues:

1. It is not inheriting the umask from its parent.

2. It does not pass its umask to its children when a dbus service is delegated to systemd, such as when the SystemdService value is set.  There is a configuration (<keep_umask>) to do so (which is not used by gnome and is the limit of the bug in gnome) but it is most certainly ignored when delegating to systemd because...

Currently, there is no good way for dbus to keep the umask as systemd does not provide a way to set the umask at runtime, or to inherit the umask of the process calling systemctl --user.

Before this issue was focused on the umask, environment variables were mentioned.  This is already supported by systemd.  The import-environment flag of systemctl --user needs to be called to enable passing the environment variables to the service.

For those looking for a workaround until a proper fix can be implemented see https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1685754/comments/21

Ray Strode, this will not fix the problem.  Systems that already do this (such as Ubuntu 18.04) result in the systemd --user process having the correct umask, the problem is it never passes the umask to its children.

Folks, sorry for the rant that will follow, but I am really astonished that this bug is now open for more than a year and that it seems to affect more or less every modern Linux distribution that uses Gnome.

TL;DR:

I think that recent Gnome based desktops are simply unusable, at least a nightmare for an admin, if the default umask of 0022 enforced by systemd on some applications is a showstopper for desktop users.

Details:

I noticed this on Ubuntu 18.04, but ISTM that at least the recent Debian
version is also affected.

I stumbled over this bug during the last weekend while trying to configure a small network (one file server, a few client machines) for an organisation where several persons will use the clients to edit and manage a larger set of documents. Every user can log on on all clients. Document management means, beside other things, to create content-specific directories on the server and to move document to their proper destination folder. Each user must be able to edit documents created by the other users. So, all files should belong to the group "users" and have the permission set to 660; directories should have the permission set to 0770.

In summary, a clear and simple case for the umask value 0007. Both for plain usability – as said, all users need write access to the commonly managed files and directories – as well as for security reasons – only users belonging to the group "users" should have access.

Coeur Noir described a pretty similar use case in comments #46 and #47 more that half a year ago.

The only workaround that seems to work is to add a file /etc/systemd/user/<application-name>.service.d/umask.conf for each and every affected application launched via "systemd --user", as described here: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1685754/comments/2

What dies this mean? I'd have to check how each and every desktop application is launched: via "systemd --user" or some other mechanism.

For a start, I've changed the umask value in /etc/login.defs and then checked the umask of Nautilus, Gimp, LibreOffice and Gedit.

Result: Gimp and Nautilus run with umask=0022, gedit and LibreOffice run with umask=0007, as specified in /etc/login.defs.

So, how should I proceed? Should I really test all applications for desktop users? Is there anywhere a comprehensive list what is installed on Ubuntu 18.04 by default? Michael Shannon recommends in the discussion of the related Ubuntu bug
(https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1685754/comments/21) to run "grep -rhoP '(?<=SystemdService=).*' /usr/share/dbus-1/services" to find all affected applications – but this does not list Nautilus and Gimp…

Moreover: I am not a full time admin for this project, I'm doing this as a hobby. Some of the regular users, who know a little bit about Debian package management and about the importance of keeping the systems up to date, have admin rights. So they can also install more desptop applications if they want or need them. Should I really try to explain to them what they have to do to ensure that these programs indeed run with umask=0007?

I'm really inclined to just drop the current installations (fortunately the whole setup is not yet in use) and to start again with KDE/Kubuntu. A quick test indicates that it's simply enough to tweak /etc/login.defs to change umask system wide, even for login shells. No hassles with "systemd --user" enforcing umask=0022 on all lauched programs :)

try putting pam_umask in /etc/pam.d/systemd-user

Ray, thanks for the suggestion. But the issue still remains: "nautilus --gapplication-service" is still running with umask=022 (stared by systemd --user) and creates directories with permission 755.

This issue was fixed in systemd by https://github.com/systemd/systemd/pull/15318. Debian cherry-picked that change into 245.4-3, so Debian bullseye and buster-backports have the fix, as does Ubuntu 20.04 (focal).

GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version of gnome-session, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/gnome-session/-/issues/

Thank you for your understanding and your help.