'systemd --user' unduly forces umask=0022

Bug #1685754 reported by Etienne URBAH on 2017-04-24
352
This bug affects 22 people
Affects Status Importance Assigned to Milestone
GNOME Terminal
Confirmed
Medium
Nautilus
Invalid
Undecided
Unassigned
gedit
Invalid
Undecided
Unassigned
gnome-session
Invalid
Undecided
Unassigned
systemd
Unknown
Unknown
dbus (Ubuntu)
Undecided
Unassigned
Bionic
Undecided
Unassigned
gnome-terminal (Ubuntu)
Undecided
Unassigned
Bionic
Undecided
Unassigned
systemd (Ubuntu)
Undecided
Unassigned
Bionic
Undecided
Unassigned

Bug Description

In order to set the default umask of my users to 027 or 007, I followed the instructions provided in 'man pam_umask' :

In the 'gecos' field of '/etc/passwd', I have inserted 'umask=027' or 'umask=007' (for myself).

Then, MOST graphical applications systematically run with the correct umask.

In particular, when I press Alt-F2, run 'xterm sh' and type 'umask', it systematically displays 0007.

But when I press Alt-F2, run 'gnome-terminal -e sh' and type 'umask', it systematically displays 0022.

That is BAD, and is a security issue.

Workaround : Inside the newly created '/etc/profile.d/umask.sh', and in each '~/.bashrc', add following content :
UMASK="$(grep -o "^$USER:.*,umask=0[0-7]*" /etc/passwd)"
if [ "$UMASK" ]; then
  umask "${UMASK#$USER:*,umask=}"
fi

In fact, 'gnome-terminal' MUST NOT force umask=022, but keep umask unchanged.

Thank you in advance for a quick correction.

ProblemType: Bug
DistroRelease: Ubuntu 17.04
Package: gnome-terminal 3.20.2-1ubuntu8
ProcVersionSignature: Ubuntu 4.10.0-19.21-generic 4.10.8
Uname: Linux 4.10.0-19-generic x86_64
ApportVersion: 2.20.4-0ubuntu4
Architecture: amd64
CurrentDesktop: X-Cinnamon
Date: Mon Apr 24 08:36:58 2017
InstallationDate: Installed on 2017-03-28 (26 days ago)
InstallationMedia: Ubuntu-GNOME 17.04 "Zesty Zapus" - Beta amd64 (20170321)
SourcePackage: gnome-terminal
UpgradeStatus: No upgrade log present (probably fresh install)

I set my umask in my .profile to 0027.

When I run most applications in my GNOME session, e.g. Emacs, or another terminal, such as xterm, the umask within is 0027.

When I run gnome-terminal (3.18.3, Ubuntu 16.04), my umask is 0002.

As far as I can tell, I am starting gnome-terminal and xterm (also tried uxterm) in the same way. Both are configured not to start a login shell.

If I run "umask" at the top of my .bashrc, in gnome-terminal it prints 0002, and in xterm, 0027.

If I run xterm from within gnome-terminal, the umask remains 0002.

Running gnome-terminal.real directly has the same effect.

I tried killing gnome-terminal-server and running gnome-terminal: same result.

If I set the umask in my .bashrc, then the setting is respected.

(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.

Etienne URBAH (eurbah) wrote :
Emily Ratliff (emilyr) wrote :

There is a discussion about a related problem in the upstream bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=780622
Since the problem space is known, I'm making the bug public and subscribing the desktop team for further assistance.

information type: Private Security → Public Security
Etienne URBAH (eurbah) wrote :

Thanks to Emily Ratliff for https://bugzilla.gnome.org/show_bug.cgi?id=780622

This permits me to provide following details :

$ 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 the 'gnome-terminal' package to start 'gnome-terminal-server' through the 'dbus' service.

Anyway, this bad 'umask=0022' hardcoding, which must be corrected, is somewhere inside the 'gnome-terminal' package.

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.

Seth Arnold (seth-arnold) wrote :

Etienne, the upstream bug comments suggest it may not be limited to just gnome-terminal. You may have success finding what component / process is performing the umask() calls via perf or auditd:

$ sudo perf record -e syscalls:sys_enter_umask -ag

-in another terminal change umask-

^C[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 1.009 MB perf.data (1 samples) ]
$ sudo perf script
bash 30279 [002] 801251.545434: syscalls:sys_enter_umask: mask: 0x00000002
                   f62f7 umask (/lib/x86_64-linux-gnu/libc-2.23.so)

OR

$ sudo auditctl -a always,exit -S umask
WARNING - 32/64 bit syscall mismatch, you should specify an arch

-in another terminal change umask-

$ sudo auditctl -d always,exit -S umask
$

then find in your /var/log/audit/audit.log a line like:

type=SYSCALL msg=audit(1493335707.490:34758): arch=c000003e syscall=95 success=yes exit=2 a0=2 a1=ffffffd0 a2=0 a3=4b4 items=0 ppid=3738 pid=30444 auid=4294967295 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts29 ses=4294967295 comm="bash" exe="/bin/bash" key=(null)

Fun fact: while testing this, I found both /usr/bin/man and /usr/bin/sudo changing umask. If you care about umask changing you might want to make this auditd rule permanent, of course addressing the 32/64 bit mismatch in 'real' use:

-a always,exit -F arch=b64 -S umask -F key=umask
-a always,exit -F arch=b32 -S umask -F key=umask

Thanks

Etienne URBAH (eurbah) wrote :

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

Inside the above provided '/var/log/audit/audit.log', 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)'.

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 ?

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. ***

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gnome-terminal (Ubuntu):
status: New → Confirmed
Greg Williams (greg2lapa) wrote :

Isn't this a gnome-session bug?

In 17.04, setting umask in $HOME/.profile has no effect on the gnome-session. Setting umask at /.profile does work in 16.04 though.

Setting umask in /.bashrc has an effect ONLY in gnome-terminal apps like nano and vi. But users still have no way to set default umask for gnome apps like LibreOffice and gedit.

@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?

Etienne URBAH (eurbah) wrote :

Yes, I think that this issue comes from the 'gnome-session' issue described at https://bugzilla.gnome.org/show_bug.cgi?id=780622

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.

Seth Arnold (seth-arnold) wrote :

I believe even Gnome on 16.04 LTS is using the upstart user session rather than system user session. This could be part of why the Gnome bug discussion seemed to go around in circles.

Other possible sources of confusion:

- ~/.profile and ~/.bashrc are strictly for shells. Nothing else reads them. This might work if you start X via the startx(1) tool after logging in to the console, like the old days.

- Setting umask via GECOS field requires pam_umask(8) to be in the PAM stack for the service in question. It may or may not be. Check /etc/pam.d/ files to be sure.

Thanks

Seth Arnold (seth-arnold) wrote :

Oh, one more possible confusion -- when a process's parent dies, it is reparented to pid 1. This guarantees that _some_ process will wait(2) on every dead child. So seeing 'ppid 1' in a process listing simply means the process's parent died before you looked for it.

Thanks

Etienne URBAH (eurbah) wrote :

$ grep '^ *[^#].*pam_umask' /etc/pam.d/*
/etc/pam.d/common-session:session optional pam_umask.so
/etc/pam.d/common-session-noninteractive:session optional pam_umask.so

Whatever sources of confusion :

Even with 'umask=007' in the 'gecos' field of '/etc/passwd', 'gnome-terminal' currently starts with umask=022.

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.

@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?

Coeur Noir (coeur-noir) wrote :

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 Budgie 17.10 where setting umask at 002 in /etc/login.defs works as expected.

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.

Coeur Noir (coeur-noir) wrote :

Files created with Gedit don't apply expected 002 umask.

But files ( or folders ) created with i.e. Gimp apply expected 002 umask.

A foreseeable way of setting umask system wide and/or per session is very much needed in order to administrate 17.10 machines in local network ( school, library, business, anything… ) where people share files/folders, be it through samba or nfs…

…that's not of low importance, it's a security issue.

Changed in gnome-terminal:
importance: Unknown → Medium
status: Unknown → Confirmed

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 ?

Etienne URBAH (eurbah) wrote :

In Ubuntu 18.04 beta 2 (Bionic), the issue is the same.

tags: added: artful bionic

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 ?

Coeur Noir (coeur-noir) wrote :

fwiw → https://bugzilla.gnome.org/show_bug.cgi?id=780622#c44 → where security issue is also mentioned.

And → https://bugzilla.gnome.org/show_bug.cgi?id=780622#c49 → in fedora we're going to start adding pam_umask to the default pam configuration so admins can edit /etc/login.defs

Does it mean Ubuntu 18.04 may benefit from it - as an LTS release, it should.

Seth Arnold (seth-arnold) wrote :

You can of course use pam_umask(8) on Ubuntu as well if you wish.

Thanks

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 (?)

Coeur Noir (coeur-noir) wrote :

You can of course use pam_umask(8) on Ubuntu as well if you wish.

→ no longer works « globally » since 17.04, hence this dicussion.

→ before 17.04 just setting your favorite umask in /etc/login.defs did the job once and for all.

Daniel (andrade) wrote :

In 16.04, I usually added `umask=0027` after `session optional pam_umask.so` in file `/etc/pam.d/common-session`. Not sure it was the appropriate place but worked for me.

No longer working in 18.04.

Shane Jaroch (gamesguru) wrote :

confirmed to affect user instance of gnome-terminal and nautilus. xterm, su, and commands run by alt+F2 are all unaffected.

Changed in nautilus:
status: New → Confirmed
Shane Jaroch (gamesguru) wrote :

does not affect gedit instances which are launched via xterm or alt+F2, so I assume it's due to the systemd --user or the gnome-terminal user session.

Changed in gedit:
status: New → Invalid

This is a bug in every GNOME application that uses systemctl --user to start itself. There is currently no sane fix because systemd is missing a feature of upstart, umask inheritance. GNOME could abuse systemd's instantiated services feature to pass the umask through this but this would be far from ideal.

A workaround for those of us that need a solution now is to place

  [Service]
  UMask=<umask value>

in

  $HOME/.config/systemd/user/gnome-terminal-server.service.d/umask.conf

for an individual user or in

  /etc/systemd/user/gnome-terminal-server.service.d/umask.conf

for all users. This will set the umask only for gnome-terminal. To get most services set an override for dbus.service as well. However, there are quite a few services that are not directly launched by dbus (like gnome-terminal-server) and need their own overrides. A list of these can be obtained by:

  $ grep -rhoP '(?<=SystemdService=).*' /usr/share/dbus-1/services

The only sane way I have come up with to deal with this is to create a single umask.conf and add a symlink to it from the <service>.serivce.d/umask.conf overide for each service found above (as well as dbus). In this way, only two files must be edited to set system default umask, /etc/login.defs and umask.conf.

Correction, I believe this is actually a bug in dbus. gnome-terminal, and others are not setting <keep_umask> as it should, but as far as I know, dbus cannot support <keep_umask> in a systemd environment due to the limitations mentioned in #21.

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.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in dbus (Ubuntu):
status: New → Confirmed
Download full text (3.4 KiB)

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 (for...

Read more...

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.

Naël (nathanael-naeri) wrote :

Does anyone know where this bug is being tracked upstream now? GNOME has migrated from Bugzilla to GitLab, and I haven't been able to find the GitLab version of the Bugzilla bug.

Etienne URBAH (eurbah) wrote :

Currently, the upstream issue has NOT been migrated to GNOME GitLab yet, but is still being tracked at https://bugzilla.gnome.org/show_bug.cgi?id=780622

Naël (nathanael-naeri) wrote :

Ah, OK, thanks. No news since 2018-08 then - I was hoping the GNOME GitLab would have something new :(

Olivier JOLY (olivier-joly) wrote :

I move too Ubuntu 19.04 and we are still affected by this bug, into multi users professional environment we usually just use LTS, but try to solve this issue without success. ;-(
Try also without success :
===============
A workaround for those of us that need a solution now is to place

  [Service]
  UMask=<umask value>

in

  $HOME/.config/systemd/user/gnome-terminal-server.service.d/umask.conf

for an individual user or in

  /etc/systemd/user/gnome-terminal-server.service.d/umask.conf
==============

Etienne URBAH (eurbah) wrote :

In order that gnome-terminal starts with the correct umask :
Lot of thanks to Olivier JOLY for comment #27 :
His workaround is effective.

Olivier JOLY (olivier-joly) wrote :

Thanks for your answer and prompt support. I tried again and find my mistake, i am using models for test that are just a copy of file without changing models permissions, without models and just create empty document and directory IT WORK :-). I confirm that the workaround is effective on 18.04.3 LTS and 19.04. Thanks again

Tom Reynolds (tomreyn) on 2019-10-27
Changed in gnome-terminal:
importance: Medium → Unknown
status: Confirmed → Unknown
David (unitedsloth) wrote :

Is there any workaround for Nautilus?
I tried with /etc/systemd/user/nautilus.service.d/umask.conf and /etc/systemd/user/Nautilus.service.d/umask.conf but nothing seems to work.
Thanks in advance!

Sven Gehr (n-sven) wrote :

i have the same problem in Ubuntu 19.10 :-(

with best

Changed in gnome-terminal:
importance: Unknown → Medium
status: Unknown → Confirmed

is there now a solution that works under Ubuntu 19.10?

/etc/systemd/user/gnome-terminal-server.service.d/umask.conf

The path from "gnome-terminal-server.service.d" does not exist here at all.

The problem should be solved after such a long time :-( .... Is there a plan how the problem can be solved?

Etienne URBAH (eurbah) wrote :

Sven, here are the workaround steps (as root) :
1) Create the folder '/etc/systemd/user/gnome-terminal-server.service.d' (with usual mode 755).
2) In this newly created folder, create the 'umask.conf' file with following content :
   [Service]
   UMask=<umask value>

Sven Gehr (n-sven) wrote :

Hello,

thanks but this setting only works in the terminal. Files or folders created from the GUI (GEdit, Nautilus ...) do not respect this UMASK :-(

Klaus Jaensch (klausj) wrote :

I think it's an systemd issue, which is already reported on GitHub but not fixed yet:

https://github.com/systemd/systemd/issues/6077

Etienne URBAH (eurbah) wrote :

With systemd version 245.2-1ubuntu2 from Ubuntu 20.04 Beta (Focal Fossa), the issue is still the same.

tags: added: eoan focal
Balint Reczey (rbalint) wrote :

@eurbah 245.4-4ubuntu1 fixed the issue in systemd.

Changed in systemd (Ubuntu):
status: New → Fix Released
Richard Hansen (rhansen) on 2020-05-10
tags: removed: focal
summary: - gnome-terminal unduly forces umask=0022
+ 'systemd --user' unduly forces umask=0022
Changed in gnome-terminal (Ubuntu):
status: Confirmed → Invalid
Changed in dbus (Ubuntu):
status: Confirmed → Invalid
Changed in gnome-session:
status: New → Invalid
Changed in nautilus:
status: Confirmed → Invalid

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).

Dan Streetman (ddstreet) on 2020-05-15
Changed in gnome-terminal (Ubuntu Bionic):
status: New → Invalid
Changed in dbus (Ubuntu Bionic):
status: New → Invalid
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in systemd (Ubuntu Bionic):
status: New → Confirmed
Etienne URBAH (eurbah) wrote :

REGRESSION: With systemd 246.6-1ubuntu1 from Ubuntu 20.10 Beta (Groovy Gorilla), the issue had reappeared

tags: added: groovy
To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.