Launchpad has imported 57 comments from the remote bug at https://bugzilla.gnome.org/show_bug.cgi?id=780622.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2017-03-27T21:38:07+00:00 Reuben Thomas wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/0 ------------------------------------------------------------------------ On 2017-03-27T21:50:36+00:00 Chpe wrote: (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). Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/1 ------------------------------------------------------------------------ On 2017-03-28T00:59:08+00:00 Reuben Thomas wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/2 ------------------------------------------------------------------------ On 2017-03-28T01:08:04+00:00 Reuben Thomas wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/3 ------------------------------------------------------------------------ On 2017-03-28T08:54:37+00:00 Reuben Thomas wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/4 ------------------------------------------------------------------------ On 2017-03-28T09:01:19+00:00 Egmont Koblinger wrote: 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.) Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/5 ------------------------------------------------------------------------ On 2017-03-28T09:09:07+00:00 Egmont Koblinger wrote: Just for the record: Could you please check the umask of your gnome- terminal-server process? grep Umask /proc/$(pidof gnome-terminal-server)/status Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/6 ------------------------------------------------------------------------ On 2017-03-28T09:24:22+00:00 Reuben Thomas wrote: 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). Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/7 ------------------------------------------------------------------------ On 2017-03-28T10:13:35+00:00 Egmont Koblinger wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/8 ------------------------------------------------------------------------ On 2017-03-28T10:21:17+00:00 Reuben Thomas wrote: The answer is, the umask of that process is 0002. Thanks very much for digging out a way for me to get it. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/9 ------------------------------------------------------------------------ On 2017-03-28T10:57:09+00:00 Chpe wrote: (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). Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/10 ------------------------------------------------------------------------ On 2017-03-28T14:16:21+00:00 Reuben Thomas wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/11 ------------------------------------------------------------------------ On 2017-03-28T14:20:08+00:00 Reuben Thomas wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/12 ------------------------------------------------------------------------ On 2017-03-28T14:37:08+00:00 Reuben Thomas wrote: 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). Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/13 ------------------------------------------------------------------------ On 2017-03-28T15:25:13+00:00 Reuben Thomas wrote: 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.) Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/14 ------------------------------------------------------------------------ On 2017-03-28T16:25:34+00:00 Chpe wrote: Try using pstree to find which process is the parent of gnome-terminal- server, and then look what that one's umask is? Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/15 ------------------------------------------------------------------------ On 2017-03-28T16:53:25+00:00 Reuben Thomas wrote: Thanks again. Using pstree -H to highlight the parent, I've confirmed it's the root systemd (PID 1). Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/16 ------------------------------------------------------------------------ On 2017-03-28T16:55:01+00:00 Reuben Thomas wrote: Confirmed with pstree --show-parents: it's PID 1. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/17 ------------------------------------------------------------------------ On 2017-03-28T16:55:31+00:00 Reuben Thomas wrote: (I presume trying to attach gdb to PID 1 to find out the umask is not a good idea.) Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/18 ------------------------------------------------------------------------ On 2017-03-28T17:04:15+00:00 Chpe wrote: 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.) Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/19 ------------------------------------------------------------------------ On 2017-03-28T17:18:05+00:00 Reuben Thomas wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/20 ------------------------------------------------------------------------ On 2017-04-05T08:00:27+00:00 Reuben Thomas wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/21 ------------------------------------------------------------------------ On 2017-04-05T08:33:08+00:00 Reuben Thomas wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/22 ------------------------------------------------------------------------ On 2017-04-05T09:39:15+00:00 Chpe wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/23 ------------------------------------------------------------------------ On 2017-04-05T09:53:00+00:00 Reuben Thomas wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/24 ------------------------------------------------------------------------ On 2017-04-05T11:19:01+00:00 Chpe wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/25 ------------------------------------------------------------------------ On 2017-04-05T13:21:41+00:00 Reuben Thomas wrote: I am running a default GNOME session from Ubuntu GNOME 16.04, which is indeed gnome-session started by gdm. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/26 ------------------------------------------------------------------------ On 2017-04-05T14:34:41+00:00 Chpe wrote: -> gnome-session for triage, although I'm not sure it's the right place either. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/27 ------------------------------------------------------------------------ On 2017-04-05T14:38:06+00:00 Reuben Thomas wrote: Thanks! Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/28 ------------------------------------------------------------------------ On 2017-04-06T15:04:44+00:00 Rstrode wrote: ~/.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? Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/29 ------------------------------------------------------------------------ On 2017-04-06T19:10:57+00:00 Reuben Thomas wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/30 ------------------------------------------------------------------------ On 2017-04-07T15:38:38+00:00 Rstrode wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/31 ------------------------------------------------------------------------ On 2017-04-07T17:59:45+00:00 Reuben Thomas wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/32 ------------------------------------------------------------------------ On 2017-04-27T23:08:14+00:00 Etienne URBAH wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/37 ------------------------------------------------------------------------ On 2017-04-30T21:02:23+00:00 Etienne URBAH wrote: 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)'. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/40 ------------------------------------------------------------------------ On 2017-05-01T08:37:26+00:00 Chpe wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/41 ------------------------------------------------------------------------ On 2017-05-01T11:47:48+00:00 Reuben Thomas wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/42 ------------------------------------------------------------------------ On 2017-05-01T13:00:38+00:00 Chpe wrote: (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*. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/43 ------------------------------------------------------------------------ On 2017-05-01T13:48:31+00:00 Reuben Thomas wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/44 ------------------------------------------------------------------------ On 2017-05-01T15:57:52+00:00 Etienne URBAH wrote: 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 ? Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/45 ------------------------------------------------------------------------ On 2017-06-25T13:53:28+00:00 Greg Williams wrote: Is this bug related to this: https://bugzilla.gnome.org/show_bug.cgi?id=784113 Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/46 ------------------------------------------------------------------------ On 2017-06-25T15:01:15+00:00 Greg Williams wrote: 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? Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/47 ------------------------------------------------------------------------ On 2017-06-28T11:13:14+00:00 Chpe wrote: *** Bug 784113 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/48 ------------------------------------------------------------------------ On 2017-06-29T15:16:59+00:00 Greg Williams wrote: @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? Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/51 ------------------------------------------------------------------------ On 2017-06-29T21:44:41+00:00 Etienne URBAH wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/53 ------------------------------------------------------------------------ On 2017-08-06T22:08:26+00:00 Greg Williams wrote: @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? Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/57 ------------------------------------------------------------------------ On 2017-11-11T01:50:58+00:00 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 i.e. Budgie 17.10 where setting umask at 002 in /etc/login.defs works as expected. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/59 ------------------------------------------------------------------------ On 2017-12-03T22:24:53+00:00 Coeur Noir wrote: 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 ? Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/61 ------------------------------------------------------------------------ On 2018-04-11T20:13:51+00:00 Etienne URBAH wrote: With systemd version 237-3ubuntu7 from Ubuntu 18.04 beta 2 (Bionic), the issue is still the same. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/63 ------------------------------------------------------------------------ On 2018-04-11T20:20:27+00:00 Rstrode wrote: fwiw, in fedora we're going to start adding pam_umask to the default pam configuration so admins can edit /etc/login.defs Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/64 ------------------------------------------------------------------------ On 2018-04-11T21:07:12+00:00 Coeur Noir wrote: 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 ? Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/65 ------------------------------------------------------------------------ On 2018-04-12T10:38:45+00:00 Rstrode wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/68 ------------------------------------------------------------------------ On 2018-04-12T17:57:37+00:00 Coeur Noir wrote: 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 (?) Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/69 ------------------------------------------------------------------------ On 2018-07-06T00:47:19+00:00 Michael Shannon wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/76 ------------------------------------------------------------------------ On 2018-08-28T13:42:22+00:00 Abel Deuring wrote: Folks, sorry for the rant that will follow, but I am really astonished that this bug is now open for more than a year and that it seems to affect more or less every modern Linux distribution that uses Gnome. TL;DR: I think that recent Gnome based desktops are simply unusable, at least a nightmare for an admin, if the default umask of 0022 enforced by systemd on some applications is a showstopper for desktop users. Details: I noticed this on Ubuntu 18.04, but ISTM that at least the recent Debian version is also affected. I stumbled over this bug during the last weekend while trying to configure a small network (one file server, a few client machines) for an organisation where several persons will use the clients to edit and manage a larger set of documents. Every user can log on on all clients. Document management means, beside other things, to create content- specific directories on the server and to move document to their proper destination folder. Each user must be able to edit documents created by the other users. So, all files should belong to the group "users" and have the permission set to 660; directories should have the permission set to 0770. In summary, a clear and simple case for the umask value 0007. Both for plain usability – as said, all users need write access to the commonly managed files and directories – as well as for security reasons – only users belonging to the group "users" should have access. Coeur Noir described a pretty similar use case in comments #46 and #47 more that half a year ago. The only workaround that seems to work is to add a file /etc/systemd/user/<application-name>.service.d/umask.conf for each and every affected application launched via "systemd --user", as described here: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/2 What dies this mean? I'd have to check how each and every desktop application is launched: via "systemd --user" or some other mechanism. For a start, I've changed the umask value in /etc/login.defs and then checked the umask of Nautilus, Gimp, LibreOffice and Gedit. Result: Gimp and Nautilus run with umask=0022, gedit and LibreOffice run with umask=0007, as specified in /etc/login.defs. So, how should I proceed? Should I really test all applications for desktop users? Is there anywhere a comprehensive list what is installed on Ubuntu 18.04 by default? Michael Shannon recommends in the discussion of the related Ubuntu bug (https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1685754/comments/21) to run "grep -rhoP '(?<=SystemdService=).*' /usr/share/dbus-1/services" to find all affected applications – but this does not list Nautilus and Gimp… Moreover: I am not a full time admin for this project, I'm doing this as a hobby. Some of the regular users, who know a little bit about Debian package management and about the importance of keeping the systems up to date, have admin rights. So they can also install more desptop applications if they want or need them. Should I really try to explain to them what they have to do to ensure that these programs indeed run with umask=0007? I'm really inclined to just drop the current installations (fortunately the whole setup is not yet in use) and to start again with KDE/Kubuntu. A quick test indicates that it's simply enough to tweak /etc/login.defs to change umask system wide, even for login shells. No hassles with "systemd --user" enforcing umask=0022 on all lauched programs :) Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/78 ------------------------------------------------------------------------ On 2018-08-28T13:45:05+00:00 Rstrode wrote: try putting pam_umask in /etc/pam.d/systemd-user Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/79 ------------------------------------------------------------------------ On 2018-08-28T15:08:08+00:00 Abel Deuring wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnome- terminal/+bug/1685754/comments/80 ** Changed in: gnome-terminal Status: Unknown => Confirmed ** Changed in: gnome-terminal Importance: Unknown => Medium ** Bug watch added: freedesktop.org Bugzilla #18446 https://bugs.freedesktop.org/show_bug.cgi?id=18446 ** Bug watch added: bugzilla.gnome.org/ #784113 https://bugzilla.gnome.org/show_bug.cgi?id=784113 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1685754 Title: gnome-terminal unduly forces umask=0022 Status in gedit: Invalid Status in gnome-session: New Status in GNOME Terminal: Confirmed Status in Nautilus: Confirmed Status in dbus package in Ubuntu: Confirmed Status in gnome-terminal package in Ubuntu: Confirmed 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) To manage notifications about this bug go to: https://bugs.launchpad.net/gedit/+bug/1685754/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
