'systemd --user' unduly forces umask=0022
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
systemd |
Unknown
|
Unknown
|
|||
systemd (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Bionic |
Fix Released
|
Medium
|
Dan Streetman |
Bug Description
[impact]
pam_umask, from /etc/passwd, is not honored in systemd --user instances
[test case]
on a desktop system, edit /etc/passwd to change the test user entry (e.g. the 'ubuntu' user) to include 'umask=007' in the GECOS field (5th field). For example change:
ubuntu:
to:
ubuntu:
You may need to reboot for your X session to pick up the change.
Then, from the graphical desktop, open a terminal and run:
$ gnome-terminal -e sh
in the opened terminal, run:
$ umask
the number shown should be 0007, as set in the passwd file
[regression potential]
any regression would likely result in an incorrect umask for the user whose passwd entry is modified.
[scope]
this is needed only for b
this is fixed in systemd upstream by commit 5e37d1930b41b24
[original 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.
UMASK="$(grep -o "^$USER:
if [ "$UMASK" ]; then
umask "${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
ProcVersionSign
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)
In bugzilla.gnome.org/ #780622, Chpe (chpe) wrote : | #33 |
(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).
In bugzilla.gnome.org/ #780622, Reuben Thomas (rrt) wrote : | #34 |
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.
In bugzilla.gnome.org/ #780622, Reuben Thomas (rrt) wrote : | #35 |
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_
fi
done
In bugzilla.gnome.org/ #780622, Reuben Thomas (rrt) wrote : | #36 |
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-
This is why I believe that something has changed the umask.
In bugzilla.gnome.org/ #780622, Egmont Koblinger (egmont-gmail) wrote : | #37 |
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:/
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:/
In bugzilla.gnome.org/ #780622, Egmont Koblinger (egmont-gmail) wrote : | #38 |
Just for the record: Could you please check the umask of your gnome-terminal-
grep Umask /proc/$(pidof gnome-terminal-
In bugzilla.gnome.org/ #780622, Reuben Thomas (rrt) wrote : | #39 |
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-
$ grep Umask /proc/$(pidof gnome-terminal-
$ echo $?
1
A quick cat of the status file confirms that there's no Umask line (or similar).
In bugzilla.gnome.org/ #780622, Egmont Koblinger (egmont-gmail) wrote : | #40 |
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://
In bugzilla.gnome.org/ #780622, Reuben Thomas (rrt) wrote : | #41 |
The answer is, the umask of that process is 0002. Thanks very much for digging out a way for me to get it.
In bugzilla.gnome.org/ #780622, Chpe (chpe) wrote : | #42 |
(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-
> set should be inherited (as occurs with xterm).
No, Xsession isn't starting g-t-server. gnome-terminal-
In bugzilla.gnome.org/ #780622, Reuben Thomas (rrt) wrote : | #43 |
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-
Presumably this problem can affect other processes, not just gnome-terminal-
In bugzilla.gnome.org/ #780622, Reuben Thomas (rrt) wrote : | #44 |
I found this bug for dbus: https:/
And indeed in my (default) Ubuntu 16.04 configuration /etc/dbus-
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/
In bugzilla.gnome.org/ #780622, Reuben Thomas (rrt) wrote : | #45 |
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-
In bugzilla.gnome.org/ #780622, Reuben Thomas (rrt) wrote : | #46 |
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/
In bugzilla.gnome.org/ #780622, Chpe (chpe) wrote : | #47 |
Try using pstree to find which process is the parent of gnome-terminal-
In bugzilla.gnome.org/ #780622, Reuben Thomas (rrt) wrote : | #48 |
Thanks again.
Using pstree -H to highlight the parent, I've confirmed it's the root systemd (PID 1).
In bugzilla.gnome.org/ #780622, Reuben Thomas (rrt) wrote : | #49 |
Confirmed with pstree --show-parents: it's PID 1.
In bugzilla.gnome.org/ #780622, Reuben Thomas (rrt) wrote : | #50 |
(I presume trying to attach gdb to PID 1 to find out the umask is not a good idea.)
In bugzilla.gnome.org/ #780622, Chpe (chpe) wrote : | #51 |
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.)
In bugzilla.gnome.org/ #780622, Reuben Thomas (rrt) wrote : | #52 |
Sorry if I've misread something or done something wrong. Here's more detail:
$ whoami
rrt
$ id -u
1000
$ pidof gnome-terminal-
26250
$ pstree -alp -H26250 -s 26250
systemd,1 splash
└─gnome-
├─bash,5594
│ └─lua,14120 /home/rrt/
│ └─pstree,14122 -alp -H26250 -s 26250
├─bash,8014
├─bash,26254
├─{dconf worker},26253
├
└
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-
I'm not logged in as root, I'm logged in as a user created in the normal way with the Ubuntu GNOME installer.
In bugzilla.gnome.org/ #780622, Reuben Thomas (rrt) wrote : | #53 |
One extra piece of information: it seems that on my system gnome-terminal is indeed started by dbus:
$ cat /usr/share/
[D-BUS Service]
Name=org.
Exec=/usr/
$ 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.
In bugzilla.gnome.org/ #780622, Reuben Thomas (rrt) wrote : | #54 |
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-
In bugzilla.gnome.org/ #780622, Chpe (chpe) wrote : | #55 |
So we've established (comment 9) that gnome-terminal-
In bugzilla.gnome.org/ #780622, Reuben Thomas (rrt) wrote : | #56 |
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/
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.
In bugzilla.gnome.org/ #780622, Chpe (chpe) wrote : | #57 |
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.
In bugzilla.gnome.org/ #780622, Reuben Thomas (rrt) wrote : | #58 |
I am running a default GNOME session from Ubuntu GNOME 16.04, which is indeed gnome-session started by gdm.
In bugzilla.gnome.org/ #780622, Chpe (chpe) wrote : | #59 |
-> gnome-session for triage, although I'm not sure it's the right place either.
In bugzilla.gnome.org/ #780622, Reuben Thomas (rrt) wrote : | #60 |
Thanks!
In bugzilla.gnome.org/ #780622, Rstrode (rstrode) wrote : | #61 |
~/.profile will not be sourced before gnome-terminal-
$ systemctl --user edit dbus
[Service]
UMask=0027
$ systemctl --user edit gnome-terminal-
[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?
In bugzilla.gnome.org/ #780622, Reuben Thomas (rrt) wrote : | #62 |
Thanks; I tried those two commands and both give an error:
No files found for gnome-terminal-
(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.
In bugzilla.gnome.org/ #780622, Rstrode (rstrode) wrote : | #63 |
there's nothing gnome-session can do really. it's not involved at all. gnome-terminal requests a service provided by gnome-terminal-
In bugzilla.gnome.org/ #780622, Reuben Thomas (rrt) wrote : | #64 |
Thanks, Ray.
I tried setting umask in ~/.bashrc before I settled on my current workaround of disabling gnome-terminal-
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 : | #1 |
- Dependencies.txt Edit (9.4 KiB, text/plain; charset="utf-8")
- JournalErrors.txt Edit (168.7 KiB, text/plain; charset="utf-8")
- ProcCpuinfoMinimal.txt Edit (1.1 KiB, text/plain; charset="utf-8")
- ProcEnviron.txt Edit (341 bytes, text/plain; charset="utf-8")
Emily Ratliff (emilyr) wrote : | #2 |
There is a discussion about a related problem in the upstream bugzilla: https:/
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 : | #3 |
Thanks to Emily Ratliff for https:/
This permits me to provide following details :
$ GTS_PID=$(pidof gnome-terminal-
$ PARENT_PID=$(ps --no-header -o ppid $GTS_PID | sed -e 's/ //g')
$ ps n -fp $GTS_PID,
UID PID PPID C STIME TTY STAT TIME CMD
1001 2551 1 0 avril27 ? Ss 0:00 /lib/systemd/
1001 4812 2551 0 avril27 ? Ssl 0:10 /usr/lib/
$ grep -e Name -e Umask /proc/{
/proc/2551/
/proc/2551/
/proc/4812/
/proc/4812/
$ cat /usr/share/
[D-BUS Service]
Name=org.
SystemdService=
Exec=/usr/
This proves that 'gnome-
This seems to point the bad 'umask=0022' hardcoding inside 'gnome-
Anyway, this bad 'umask=0022' hardcoding, which must be corrected, is somewhere inside the 'gnome-terminal' package.
In bugzilla.gnome.org/ #780622, Etienne URBAH (eurbah) wrote : | #65 |
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:/
$ GTS_PID=$(pidof gnome-terminal-
$ PARENT_PID=$(ps --no-header -o ppid $GTS_PID | sed -e 's/ //g')
$ ps n -fp $GTS_PID,
UID PID PPID C STIME TTY STAT TIME CMD
1001 2551 1 0 avril27 ? Ss 0:00 /lib/systemd/
1001 4812 2551 0 avril27 ? Ssl 0:10 /usr/lib/
$ grep -e Name -e Umask /proc/{
/proc/2551/
/proc/2551/
/proc/4812/
/proc/4812/
$ cat /usr/share/
[D-BUS Service]
Name=org.
SystemdService=
Exec=/usr/
This proves that 'gnome-
This seems to point the bad 'umask=0022' hardcoding inside 'gnome-
Anyway, this bad 'umask=0022' hardcoding, which must be corrected, is somewhere inside GNOME.
Seth Arnold (seth-arnold) wrote : | #4 |
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:
-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:
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/
type=SYSCALL msg=audit(
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 : | #5 |
Thanks to Seth Arnold for his advices to use the 'perf' or 'auditd' tools.
Inside the above provided '/var/log/
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:
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:
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-
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-
> systemd-journal 360 [005] 10229.742513: syscalls:
> f7907 __GI___umask (/lib/x86_
> 0 [unknown] ([unknown])
>
> systemd-journal 360 [005] 10229.742521: syscalls:
> f7907 __GI___umask (/lib/x86_
>
> (l-server) 12464 [003] 10229.742634: syscalls:
> f7907 __GI___umask (/lib/x86_
> 8f2af [unknown] (/lib/systemd/
>
> bash 12472 [005] 10229.881381: syscalls:
> f7907 __GI___umask (/lib/x86_
> 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)'.
In bugzilla.gnome.org/ #780622, Etienne URBAH (eurbah) wrote : | #66 |
Thanks to Seth Arnold for his advices to use the 'perf' or 'auditd' tools.
Inside the example '/var/log/
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:
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:
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-
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-
> systemd-journal 360 [005] 10229.742513: syscalls:
> f7907 __GI___umask (/lib/x86_
> 0 [unknown] ([unknown])
>
> systemd-journal 360 [005] 10229.742521: syscalls:
> f7907 __GI___umask (/lib/x86_
>
> (l-server) 12464 [003] 10229.742634: syscalls:
> f7907 __GI___umask (/lib/x86_
> 8f2af [unknown] (/lib/systemd/
>
> bash 12472 [005] 10229.881381: syscalls:
> f7907 __GI___umask (/lib/x86_
> 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)'.
In bugzilla.gnome.org/ #780622, Chpe (chpe) wrote : | #67 |
Again, gnome-terminal-
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:/
I suggest RESOLVED:INVALID for this bug.
In bugzilla.gnome.org/ #780622, Reuben Thomas (rrt) wrote : | #68 |
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 bugzilla.gnome.org/ #780622, Chpe (chpe) wrote : | #69 |
(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 bugzilla.gnome.org/ #780622, Reuben Thomas (rrt) wrote : | #70 |
(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-
In bugzilla.gnome.org/ #780622, Etienne URBAH (eurbah) wrote : | #71 |
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-
- 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:/
- Is it possible to document in which section of which file this option has to be set ?
In bugzilla.gnome.org/ #780622, Greg Williams (greg2lapa) wrote : | #72 |
Is this bug related to this: https:/
In bugzilla.gnome.org/ #780622, Greg Williams (greg2lapa) wrote : | #73 |
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?
In bugzilla.gnome.org/ #780622, Chpe (chpe) wrote : | #74 |
*** Bug 784113 has been marked as a duplicate of this bug. ***
Launchpad Janitor (janitor) wrote : | #6 |
Status changed to 'Confirmed' because the bug affects multiple users.
Changed in gnome-terminal (Ubuntu): | |
status: | New → Confirmed |
Greg Williams (greg2lapa) wrote : | #7 |
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.
In bugzilla.gnome.org/ #780622, Greg Williams (greg2lapa) wrote : | #75 |
@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 : | #8 |
Yes, I think that this issue comes from the 'gnome-session' issue described at https:/
In bugzilla.gnome.org/ #780622, Etienne URBAH (eurbah) wrote : | #76 |
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 : | #9 |
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 : | #10 |
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 : | #11 |
$ grep '^ *[^#].*pam_umask' /etc/pam.d/*
/etc/pam.
/etc/pam.
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.
In bugzilla.gnome.org/ #780622, Greg Williams (greg2lapa) wrote : | #77 |
@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 : | #12 |
Hello,
That bug is not fixed in 17.10 !
For reference : https:/
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.
In bugzilla.gnome.org/ #780622, Coeur Noir (coeur-noir) wrote : | #78 |
Hello,
That bug is not fixed in 17.10 !
For reference : https:/
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 : | #13 |
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 |
In bugzilla.gnome.org/ #780622, Coeur Noir (coeur-noir) wrote : | #79 |
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 : | #14 |
In Ubuntu 18.04 beta 2 (Bionic), the issue is the same.
tags: | added: artful bionic |
In bugzilla.gnome.org/ #780622, Etienne URBAH (eurbah) wrote : | #80 |
With systemd version 237-3ubuntu7 from Ubuntu 18.04 beta 2 (Bionic), the issue is still the same.
In bugzilla.gnome.org/ #780622, Rstrode (rstrode) wrote : | #81 |
fwiw, in fedora we're going to start adding pam_umask to the default pam configuration so admins can edit /etc/login.defs
In bugzilla.gnome.org/ #780622, Coeur Noir (coeur-noir) wrote : | #82 |
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 : | #15 |
fwiw → https:/
And → https:/
Does it mean Ubuntu 18.04 may benefit from it - as an LTS release, it should.
Seth Arnold (seth-arnold) wrote : | #16 |
You can of course use pam_umask(8) on Ubuntu as well if you wish.
Thanks
In bugzilla.gnome.org/ #780622, Rstrode (rstrode) wrote : | #83 |
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
In bugzilla.gnome.org/ #780622, Coeur Noir (coeur-noir) wrote : | #84 |
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 : | #17 |
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 : | #18 |
In 16.04, I usually added `umask=0027` after `session optional pam_umask.so` in file `/etc/pam.
No longer working in 18.04.
Shane Jaroch (gamesguru) wrote : | #19 |
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 : | #20 |
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 |
Michael Shannon (mrshannon-aerospace) wrote : | #21 |
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/
for an individual user or in
/etc/
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-
$ grep -rhoP '(?<=SystemdSer
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>
Michael Shannon (mrshannon-aerospace) wrote : | #22 |
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.
In bugzilla.gnome.org/ #780622, Michael Shannon (mrshannon-aerospace) wrote : | #85 |
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:/
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 : | #23 |
Status changed to 'Confirmed' because the bug affects multiple users.
Changed in dbus (Ubuntu): | |
status: | New → Confirmed |
In bugzilla.gnome.org/ #780622, Abel Deuring (adeuring) wrote : | #86 |
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/
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:/
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...
In bugzilla.gnome.org/ #780622, Rstrode (rstrode) wrote : | #87 |
try putting pam_umask in /etc/pam.
In bugzilla.gnome.org/ #780622, Abel Deuring (adeuring) wrote : | #88 |
Ray, thanks for the suggestion. But the issue still remains: "nautilus --gapplication-
Naël (nathanael-naeri) wrote : | #24 |
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 : | #25 |
Currently, the upstream issue has NOT been migrated to GNOME GitLab yet, but is still being tracked at https:/
Naël (nathanael-naeri) wrote : | #26 |
Ah, OK, thanks. No news since 2018-08 then - I was hoping the GNOME GitLab would have something new :(
Olivier JOLY (olivier-joly) wrote : | #27 |
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/
for an individual user or in
/etc/
==============
Etienne URBAH (eurbah) wrote : | #28 |
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 : | #29 |
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
Changed in gnome-terminal: | |
importance: | Medium → Unknown |
status: | Confirmed → Unknown |
David (unitedsloth) wrote : | #30 |
Is there any workaround for Nautilus?
I tried with /etc/systemd/
Thanks in advance!
Sven Gehr (n-sven) wrote : | #31 |
i have the same problem in Ubuntu 19.10 :-(
with best
Changed in gnome-terminal: | |
importance: | Unknown → Medium |
status: | Unknown → Confirmed |
Sven Gehr (n-sven) wrote : Re: gnome-terminal unduly forces umask=0022 | #89 |
is there now a solution that works under Ubuntu 19.10?
/etc/systemd/
The path from "gnome-
The problem should be solved after such a long time :-( .... Is there a plan how the problem can be solved?
Etienne URBAH (eurbah) wrote : | #90 |
Sven, here are the workaround steps (as root) :
1) Create the folder '/etc/systemd/
2) In this newly created folder, create the 'umask.conf' file with following content :
[Service]
UMask=<umask value>
Sven Gehr (n-sven) wrote : | #91 |
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 : | #92 |
I think it's an systemd issue, which is already reported on GitHub but not fixed yet:
Etienne URBAH (eurbah) wrote : | #93 |
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 : | #94 |
@eurbah 245.4-4ubuntu1 fixed the issue in systemd.
Changed in systemd (Ubuntu): | |
status: | New → Fix Released |
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 |
In bugzilla.gnome.org/ #780622, A7x-gnome (a7x-gnome) wrote : | #95 |
This issue was fixed in systemd by https:/
Changed in gnome-terminal (Ubuntu Bionic): | |
status: | New → Invalid |
Changed in dbus (Ubuntu Bionic): | |
status: | New → Invalid |
Launchpad Janitor (janitor) wrote : | #96 |
Status changed to 'Confirmed' because the bug affects multiple users.
Changed in systemd (Ubuntu Bionic): | |
status: | New → Confirmed |
Etienne URBAH (eurbah) wrote : | #97 |
REGRESSION: With systemd 246.6-1ubuntu1 from Ubuntu 20.10 Beta (Groovy Gorilla), the issue had reappeared
tags: | added: groovy |
Dan Streetman (ddstreet) wrote : | #98 |
> REGRESSION: With systemd 246.6-1ubuntu1 from Ubuntu 20.10 Beta (Groovy Gorilla), the issue had reappeared
I just tested with groovy and can't reproduce the issue; umask is correct under gnome-terminal
description: | updated |
Changed in systemd (Ubuntu Bionic): | |
assignee: | nobody → Dan Streetman (ddstreet) |
importance: | Undecided → Medium |
status: | Confirmed → In Progress |
Etienne URBAH (eurbah) wrote : | #99 |
Inside Ubuntu 20.10 (Groovy Gorilla), I just tested with systemd versions 246.6-1ubuntu1 and 246.6-1ubuntu1.1 :
The issue has disappeared; umask is correct under gnome-terminal.
So, I remove the 'groovy' tag.
tags: | removed: groovy |
Łukasz Zemczak (sil2100) wrote : Please test proposed package | #100 |
Hello Etienne, or anyone else affected,
Accepted systemd into bionic-proposed. The package will build now and be available at https:/
Please help us by testing this new package. See https:/
If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-
Further information regarding the verification process can be found at https:/
N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.
Changed in systemd (Ubuntu Bionic): | |
status: | In Progress → Fix Committed |
tags: | added: verification-needed verification-needed-bionic |
Ubuntu SRU Bot (ubuntu-sru-bot) wrote : Autopkgtest regression report (systemd/237-3ubuntu10.45) | #101 |
All autopkgtests for the newly accepted systemd (237-3ubuntu10.45) for bionic have finished running.
The following regressions have been reported in tests triggered by the package:
corosync/
lxc/3.0.
openssh/
linux-hwe-
linux-hwe-
gvfs/1.
Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUp
https:/
[1] https:/
Thank you!
no longer affects: | dbus (Ubuntu) |
no longer affects: | dbus (Ubuntu Bionic) |
no longer affects: | gnome-terminal (Ubuntu) |
no longer affects: | gnome-terminal (Ubuntu Bionic) |
affects: | nautilus → ubuntu-translations |
no longer affects: | ubuntu-translations |
affects: | gedit → ubuntu-translations |
no longer affects: | ubuntu-translations |
affects: | gnome-session → ubuntu-translations |
no longer affects: | ubuntu-translations |
affects: | gnome-terminal → ubuntu-translations |
no longer affects: | ubuntu-translations |
Dan Streetman (ddstreet) wrote : | #102 |
(commands below run from graphical window)
ubuntu@
ii systemd 237-3ubuntu10.44 amd64 system and service manager
ubuntu@
ubuntu:
ubuntu@
0022
ubuntu@
ii systemd 237-3ubuntu10.45 amd64 system and service manager
ubuntu@
ubuntu:
ubuntu@
0007
tags: |
added: verification-done verification-done-bionic removed: verification-needed verification-needed-bionic |
Launchpad Janitor (janitor) wrote : | #103 |
This bug was fixed in the package systemd - 237-3ubuntu10.45
---------------
systemd (237-3ubuntu10.45) bionic; urgency=medium
[ Ioanna Alifieraki ]
* d/p/lp1911187-
Do not shutdown immediately when scheduled shutdown fails (LP: #1911187)
https:/
[ Dimitri John Ledkov ]
* d/p/lp1878969-
meson: initialize time-epoch to reproducible builds compatible value
(LP: #1878969)
https:/
[ Dan Streetman ]
* d/p/lp1913189-
- Fix failing test case under 5.8 kernel (LP: #1913189)
https:/
* d/p/lp1913423-
Thread-safe init of hashmap shared key (LP: #1913423)
https:/
* d/p/lp1890448-
Add EliteBook to use micmute hotkey (LP: #1890448)
https:/
* d/p/debian/
Disable TEST-03 run under qemu (LP: #1902553)
https:/
* d/p/debian/
Add *time64 syscalls (LP: #1883447)
https:/
* d/p/lp1685754-
Inherit umask for --user processes (LP: #1685754)
https:/
* d/p/debian/
Change NXDOMAIN 'errors' to log level debug (LP: #1880258)
https:/
* d/p/lp1913763-
Create symlink for hyperv-provided ptp device (LP: #1913763)
https:/
-- Ioanna Alifieraki <email address hidden> Tue, 23 Feb 2021 03:45:01 +0200
Changed in systemd (Ubuntu Bionic): | |
status: | Fix Committed → Fix Released |
Łukasz Zemczak (sil2100) wrote : Update Released | #104 |
The verification of the Stable Release Update for systemd has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.
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.