Comment 4 for bug 1685754

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