gnome-terminal unduly forces umask=0022

Bug #1685754 reported by Etienne URBAH on 2017-04-24
This bug affects 15 people
Affects Status Importance Assigned to Milestone
GNOME Terminal
dbus (Ubuntu)
gnome-terminal (Ubuntu)

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/', and in each '~/.bashrc', add following content :
UMASK="$(grep -o "^$USER:.*,umask=0[0-7]*" /etc/passwd)"
if [ "$UMASK" ]; then
  umask "${UMASK#$USER:*,umask=}"

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)

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

There is a discussion about a related problem in the upstream bugzilla:
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

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
    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]

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.

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 (1 samples) ]
$ sudo perf script
bash 30279 [002] 801251.545434: syscalls:sys_enter_umask: mask: 0x00000002
                   f62f7 umask (/lib/x86_64-linux-gnu/


$ 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


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/
> 0 [unknown] ([unknown])
> systemd-journal 360 [005] 10229.742521: syscalls:sys_enter_umask: mask: 0x00000012
> f7907 __GI___umask (/lib/x86_64-linux-gnu/
> (l-server) 12464 [003] 10229.742634: syscalls:sys_enter_umask: mask: 0x00000012
> f7907 __GI___umask (/lib/x86_64-linux-gnu/
> 8f2af [unknown] (/lib/systemd/systemd)
> bash 12472 [005] 10229.881381: syscalls:sys_enter_umask: mask: 0x00000007
> f7907 __GI___umask (/lib/x86_64-linux-gnu/
> 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)'.

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.

Etienne URBAH (eurbah) wrote :

Yes, I think that this issue comes from the 'gnome-session' issue described at

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.


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.


Etienne URBAH (eurbah) wrote :

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

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.

Coeur Noir (coeur-noir) wrote :


That bug is not fixed in 17.10 !

For reference :

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.

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
Etienne URBAH (eurbah) wrote :

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

tags: added: artful bionic
Coeur Noir (coeur-noir) wrote :

fwiw → → where security issue is also mentioned.

And → → 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.


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` 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

  UMask=<umask value>



for an individual user or in


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.

Launchpad Janitor (janitor) wrote :

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

Changed in dbus (Ubuntu):
status: New → Confirmed
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

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

  UMask=<umask value>



for an individual user or in


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

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.