'systemd --user' unduly forces umask=0022

Bug #1685754 reported by Etienne URBAH
354
This bug affects 22 people
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:x:1000:1000:Ubuntu:/home/ubuntu:/bin/bash

to:

ubuntu:x:1000:1000:Ubuntu,umask=007:/home/ubuntu:/bin/bash

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 5e37d1930b41b24c077ce37c6db0e36c745106c7 which was first included in v246, so this is fixed in g and later. This commit was also picked up by Debian and included in the v245 release for focal, so this is fixed in focal already.

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

Revision history for this message
In , Reuben Thomas (rrt) 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.

Revision history for this message
In , Chpe (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).

Revision history for this message
In , Reuben Thomas (rrt) 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.

Revision history for this message
In , Reuben Thomas (rrt) 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

Revision history for this message
In , Reuben Thomas (rrt) 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.

Revision history for this message
In , Egmont Koblinger (egmont-gmail) 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.)

Revision history for this message
In , Egmont Koblinger (egmont-gmail) 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

Revision history for this message
In , Reuben Thomas (rrt) 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).

Revision history for this message
In , Egmont Koblinger (egmont-gmail) 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.

38 comments hidden view all 104 comments
Revision history for this message
Etienne URBAH (eurbah) wrote :
Revision history for this message
Emily Ratliff (emilyr) wrote :

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

information type: Private Security → Public Security
Revision history for this message
Etienne URBAH (eurbah) wrote :

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

This permits me to provide following details :

$ GTS_PID=$(pidof gnome-terminal-server)

$ PARENT_PID=$(ps --no-header -o ppid $GTS_PID | sed -e 's/ //g')

$ ps n -fp $GTS_PID,$PARENT_PID
     UID PID PPID C STIME TTY STAT TIME CMD
    1001 2551 1 0 avril27 ? Ss 0:00 /lib/systemd/systemd --user
    1001 4812 2551 0 avril27 ? Ssl 0:10 /usr/lib/gnome-terminal/gnome-terminal-server

$ grep -e Name -e Umask /proc/{$GTS_PID,$PARENT_PID}/status | sort
/proc/2551/status:Name: systemd
/proc/2551/status:Umask: 0007
/proc/4812/status:Name: gnome-terminal-
/proc/4812/status:Umask: 0022

$ cat /usr/share/dbus-1/services/org.gnome.Terminal.service
[D-BUS Service]
Name=org.gnome.Terminal
SystemdService=gnome-terminal-server.service
Exec=/usr/lib/gnome-terminal/gnome-terminal-server

This proves that 'gnome-terminal-server' has the wrong 0022 umask, although it is started by 'systemd' in user mode with the right 0007 umask.

This seems to point the bad 'umask=0022' hardcoding inside 'gnome-terminal-server' and/or inside the method defined by the 'gnome-terminal' package to start 'gnome-terminal-server' through the 'dbus' service.

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

61 comments hidden view all 104 comments
Revision history for this message
In , Etienne URBAH (eurbah) 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.

60 comments hidden view all 104 comments
Revision history for this message
Seth Arnold (seth-arnold) wrote :

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

$ sudo perf record -e syscalls:sys_enter_umask -ag

-in another terminal change umask-

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

OR

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

-in another terminal change umask-

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

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

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

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

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

Thanks

Revision history for this message
Etienne URBAH (eurbah) wrote :

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

Inside the above provided '/var/log/audit/audit.log', I do NOT find the 'umask' string.

So, I prefer to begin installing and using the 'perf' tool :

$ sudo apt-get install linux-tools-generic

Close the graphical session.

Record 'umask' for a Gnome session without doing anything
---------------------------------------------------------

  Switch to a console (tty2), and login.

  $ sudo perf record -ag -e syscalls:sys_enter_umask

  Switch to the 'gdm' login screen.

  Open a Gnome session, then immediately close it.

  Switch to the console (tty2).

  Press Ctrl-C.
  ... (325 samples)

  $ sudo perf script > gnome-umask.log

Record 'umask' for a Gnome session with a Gnome terminal
--------------------------------------------------------

  $ sudo perf record -ag -e syscalls:sys_enter_umask

  Switch to the 'gdm' login screen.

  Open a Gnome session.

  Inside the Gnome session, open a Gnome terminal with Ctrl-Alt-T.

  Close the Gnome terminal with Ctrl-D.

  Close the Gnome session.

  Switch to the console (tty2).

  Press (Ctrl C).
  ... (329 samples)

  $ sudo perf script > gnome-umask-with-gnome-terminal.log

Additional traces triggered by Gnome terminal
---------------------------------------------
Following command eases the discovery of the additional traces :
$ diff -I '[0-9]* *\[ *[0-9]* *\] *[0-9.]*' gnome-umask.log gnome-umask-with-gnome-terminal.log

> systemd-journal 360 [005] 10229.742513: syscalls:sys_enter_umask: mask: 0x0000003f
> f7907 __GI___umask (/lib/x86_64-linux-gnu/libc-2.24.so)
> 0 [unknown] ([unknown])
>
> systemd-journal 360 [005] 10229.742521: syscalls:sys_enter_umask: mask: 0x00000012
> f7907 __GI___umask (/lib/x86_64-linux-gnu/libc-2.24.so)
>
> (l-server) 12464 [003] 10229.742634: syscalls:sys_enter_umask: mask: 0x00000012
> f7907 __GI___umask (/lib/x86_64-linux-gnu/libc-2.24.so)
> 8f2af [unknown] (/lib/systemd/systemd)
>
> bash 12472 [005] 10229.881381: syscalls:sys_enter_umask: mask: 0x00000007
> f7907 __GI___umask (/lib/x86_64-linux-gnu/libc-2.24.so)
> 1e0e1a8 [unknown] ([unknown])

Interpretation of the additional traces triggered by Gnome terminal
-------------------------------------------------------------------
The 'bash' trace logically comes from the 'umask 007' command in my '.bashrc' file.

Since 0022=0x12, the suspect for 'umask 022' hardcoding is '(l-server)'.

60 comments hidden view all 104 comments
Revision history for this message
In , Etienne URBAH (eurbah) 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)'.

Revision history for this message
In , Chpe (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.

Revision history for this message
In , Reuben Thomas (rrt) 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.

Revision history for this message
In , Chpe (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*.

Revision history for this message
In , Reuben Thomas (rrt) 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.

Revision history for this message
In , Etienne URBAH (eurbah) 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 ?

Revision history for this message
In , Greg Williams (greg2lapa) wrote :
Revision history for this message
In , Greg Williams (greg2lapa) 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?

Revision history for this message
In , Chpe (chpe) wrote :

*** Bug 784113 has been marked as a duplicate of this bug. ***

67 comments hidden view all 104 comments
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in gnome-terminal (Ubuntu):
status: New → Confirmed
Revision history for this message
Greg Williams (greg2lapa) wrote :

Isn't this a gnome-session bug?

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

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

67 comments hidden view all 104 comments
Revision history for this message
In , Greg Williams (greg2lapa) 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?

66 comments hidden view all 104 comments
Revision history for this message
Etienne URBAH (eurbah) wrote :

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

67 comments hidden view all 104 comments
Revision history for this message
In , Etienne URBAH (eurbah) 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.

66 comments hidden view all 104 comments
Revision history for this message
Seth Arnold (seth-arnold) wrote :

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

Other possible sources of confusion:

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

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

Thanks

Revision history for this message
Seth Arnold (seth-arnold) wrote :

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

Thanks

Revision history for this message
Etienne URBAH (eurbah) wrote :

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

Whatever sources of confusion :

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

I confirm that this issue is a security issue, which must be corrected.

IMHO, the best fix would be that GNOME systematically uses the standard 'pam_umask' module.

65 comments hidden view all 104 comments
Revision history for this message
In , Greg Williams (greg2lapa) 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?

64 comments hidden view all 104 comments
Revision history for this message
Coeur Noir (coeur-noir) wrote :

Hello,

That bug is not fixed in 17.10 !

For reference : https://forum.ubuntu-fr.org/viewtopic.php?pid=21823638#p21823638

tl;dr → umask is set at 002 in ~/.profile AND in /etc/login.defs
but new folders created through Nautilus ( or terminal ) don't grant write permission for group.
Unless if created in desktop folder ( why ? ).

That's a big problem in multi-users environment.

Other curiosity, I don't have that problem with Budgie 17.10 where setting umask at 002 in /etc/login.defs works as expected.

65 comments hidden view all 104 comments
Revision history for this message
In , Coeur Noir (coeur-noir) wrote :

Hello,

That bug is not fixed in 17.10 !

For reference : https://forum.ubuntu-fr.org/viewtopic.php?pid=21823638#p21823638

tl;dr → umask is set at 002 in ~/.profile AND in /etc/login.defs
but new folders created through Nautilus ( or terminal ) don't grant write permission for group.
Unless if created in desktop folder ( why ? ).

That's a big problem in multi-users environment.

Other curiosity, I don't have that problem with i.e. Budgie 17.10 where setting umask at 002 in /etc/login.defs works as expected.

64 comments hidden view all 104 comments
Revision history for this message
Coeur Noir (coeur-noir) wrote :

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

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

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

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

Changed in gnome-terminal:
importance: Unknown → Medium
status: Unknown → Confirmed
65 comments hidden view all 104 comments
Revision history for this message
In , Coeur Noir (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 ?

64 comments hidden view all 104 comments
Revision history for this message
Etienne URBAH (eurbah) wrote :

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

tags: added: artful bionic
65 comments hidden view all 104 comments
Revision history for this message
In , Etienne URBAH (eurbah) wrote :

With systemd version 237-3ubuntu7 from Ubuntu 18.04 beta 2 (Bionic), the issue is still the same.

Revision history for this message
In , Rstrode (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

Revision history for this message
In , Coeur Noir (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 ?

66 comments hidden view all 104 comments
Revision history for this message
Coeur Noir (coeur-noir) wrote :

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

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

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

Revision history for this message
Seth Arnold (seth-arnold) wrote :

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

Thanks

66 comments hidden view all 104 comments
Revision history for this message
In , Rstrode (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

Revision history for this message
In , Coeur Noir (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 (?)

66 comments hidden view all 104 comments
Revision history for this message
Coeur Noir (coeur-noir) wrote :

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

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

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

Revision history for this message
Daniel (andrade) wrote :

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

No longer working in 18.04.

Revision history for this message
Shane Jaroch (gamesguru) wrote :

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

Changed in nautilus:
status: New → Confirmed
Revision history for this message
Shane Jaroch (gamesguru) wrote :

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

Changed in gedit:
status: New → Invalid
Revision history for this message
Michael Shannon (mrshannon-aerospace) wrote :

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

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

  [Service]
  UMask=<umask value>

in

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

for an individual user or in

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

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

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

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

Revision history for this message
Michael Shannon (mrshannon-aerospace) wrote :

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.

62 comments hidden view all 104 comments
Revision history for this message
In , Michael Shannon (mrshannon-aerospace) 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.

61 comments hidden view all 104 comments
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in dbus (Ubuntu):
status: New → Confirmed
62 comments hidden view all 104 comments
Revision history for this message
In , Abel Deuring (adeuring) wrote :
Download full text (3.4 KiB)

Folks, sorry for the rant that will follow, but I am really astonished that this bug is now open for more than a year and that it seems to affect more or less every modern Linux distribution that uses Gnome.

TL;DR:

I think that recent Gnome based desktops are simply unusable, at least a nightmare for an admin, if the default umask of 0022 enforced by systemd on some applications is a showstopper for desktop users.

Details:

I noticed this on Ubuntu 18.04, but ISTM that at least the recent Debian
version is also affected.

I stumbled over this bug during the last weekend while trying to configure a small network (one file server, a few client machines) for an organisation where several persons will use the clients to edit and manage a larger set of documents. Every user can log on on all clients. Document management means, beside other things, to create content-specific directories on the server and to move document to their proper destination folder. Each user must be able to edit documents created by the other users. So, all files should belong to the group "users" and have the permission set to 660; directories should have the permission set to 0770.

In summary, a clear and simple case for the umask value 0007. Both for plain usability – as said, all users need write access to the commonly managed files and directories – as well as for security reasons – only users belonging to the group "users" should have access.

Coeur Noir described a pretty similar use case in comments #46 and #47 more that half a year ago.

The only workaround that seems to work is to add a file /etc/systemd/user/<application-name>.service.d/umask.conf for each and every affected application launched via "systemd --user", as described here: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1685754/comments/2

What dies this mean? I'd have to check how each and every desktop application is launched: via "systemd --user" or some other mechanism.

For a start, I've changed the umask value in /etc/login.defs and then checked the umask of Nautilus, Gimp, LibreOffice and Gedit.

Result: Gimp and Nautilus run with umask=0022, gedit and LibreOffice run with umask=0007, as specified in /etc/login.defs.

So, how should I proceed? Should I really test all applications for desktop users? Is there anywhere a comprehensive list what is installed on Ubuntu 18.04 by default? Michael Shannon recommends in the discussion of the related Ubuntu bug
(https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1685754/comments/21) to run "grep -rhoP '(?<=SystemdService=).*' /usr/share/dbus-1/services" to find all affected applications – but this does not list Nautilus and Gimp…

Moreover: I am not a full time admin for this project, I'm doing this as a hobby. Some of the regular users, who know a little bit about Debian package management and about the importance of keeping the systems up to date, have admin rights. So they can also install more desptop applications if they want or need them. Should I really try to explain to them what they have to do to ensure that these programs indeed run with umask=0007?

I'm really inclined to just drop the current installations (for...

Read more...

Revision history for this message
In , Rstrode (rstrode) wrote :

try putting pam_umask in /etc/pam.d/systemd-user

Revision history for this message
In , Abel Deuring (adeuring) 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.

63 comments hidden view all 104 comments
Revision history for this message
Naël (nathanael-naeri) wrote :

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

Revision history for this message
Etienne URBAH (eurbah) wrote :

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

Revision history for this message
Naël (nathanael-naeri) wrote :

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

Revision history for this message
Olivier JOLY (olivier-joly) wrote :

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

  [Service]
  UMask=<umask value>

in

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

for an individual user or in

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

Revision history for this message
Etienne URBAH (eurbah) wrote :

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

Revision history for this message
Olivier JOLY (olivier-joly) wrote :

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

Tom Reynolds (tomreyn)
Changed in gnome-terminal:
importance: Medium → Unknown
status: Confirmed → Unknown
Revision history for this message
David (unitedsloth) wrote :

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

Revision history for this message
Sven Gehr (n-sven) wrote :

i have the same problem in Ubuntu 19.10 :-(

with best

Changed in gnome-terminal:
importance: Unknown → Medium
status: Unknown → Confirmed
57 comments hidden view all 104 comments
Revision history for this message
Sven Gehr (n-sven) wrote : Re: gnome-terminal unduly forces umask=0022

is there now a solution that works under Ubuntu 19.10?

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

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

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

Revision history for this message
Etienne URBAH (eurbah) wrote :

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

Revision history for this message
Sven Gehr (n-sven) wrote :

Hello,

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

Revision history for this message
Klaus Jaensch (klausj) wrote :

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

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

Revision history for this message
Etienne URBAH (eurbah) wrote :

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

tags: added: eoan focal
Revision history for this message
Balint Reczey (rbalint) wrote :

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

Changed in systemd (Ubuntu):
status: New → Fix Released
Richard Hansen (rhansen)
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
Revision history for this message
In , A7x-gnome (a7x-gnome) wrote :

This issue was fixed in systemd by https://github.com/systemd/systemd/pull/15318. Debian cherry-picked that change into 245.4-3, so Debian bullseye and buster-backports have the fix, as does Ubuntu 20.04 (focal).

Dan Streetman (ddstreet)
Changed in gnome-terminal (Ubuntu Bionic):
status: New → Invalid
Changed in dbus (Ubuntu Bionic):
status: New → Invalid
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in systemd (Ubuntu Bionic):
status: New → Confirmed
Revision history for this message
Etienne URBAH (eurbah) wrote :

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

tags: added: groovy
Revision history for this message
Dan Streetman (ddstreet) wrote :

> 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

Dan Streetman (ddstreet)
description: updated
Dan Streetman (ddstreet)
Changed in systemd (Ubuntu Bionic):
assignee: nobody → Dan Streetman (ddstreet)
importance: Undecided → Medium
status: Confirmed → In Progress
Revision history for this message
Etienne URBAH (eurbah) wrote :

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
Revision history for this message
Łukasz Zemczak (sil2100) wrote : Please test proposed package

Hello Etienne, or anyone else affected,

Accepted systemd into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/237-3ubuntu10.45 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

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-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

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
Revision history for this message
Ubuntu SRU Bot (ubuntu-sru-bot) wrote : Autopkgtest regression report (systemd/237-3ubuntu10.45)

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/2.4.3-0ubuntu1.1 (armhf)
lxc/3.0.3-0ubuntu1~18.04.1 (amd64)
openssh/1:7.6p1-4ubuntu0.3 (amd64, ppc64el, arm64, i386, armhf, s390x)
linux-hwe-5.0/5.0.0-65.71 (i386)
linux-hwe-5.4/5.4.0-67.75~18.04.1 (i386)
gvfs/1.36.1-0ubuntu1.3.3 (amd64)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

Mathew Hodson (mhodson)
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
Mathew Hodson (mhodson)
affects: gnome-terminal → ubuntu-translations
no longer affects: ubuntu-translations
Revision history for this message
Dan Streetman (ddstreet) wrote :

(commands below run from graphical window)

ubuntu@lp1685754-b:~$ dpkg -l systemd |grep systemd
ii systemd 237-3ubuntu10.44 amd64 system and service manager
ubuntu@lp1685754-b:~$ grep umask /etc/passwd
ubuntu:x:1000:1000:Ubuntu,umask=007:/home/ubuntu:/bin/bash
ubuntu@lp1685754-b:~$ umask
0022

ubuntu@lp1685754-b:~$ dpkg -l systemd|grep systemd
ii systemd 237-3ubuntu10.45 amd64 system and service manager
ubuntu@lp1685754-b:~$ grep umask /etc/passwd
ubuntu:x:1000:1000:Ubuntu,umask=007:/home/ubuntu:/bin/bash
ubuntu@lp1685754-b:~$ umask
0007

tags: added: verification-done verification-done-bionic
removed: verification-needed verification-needed-bionic
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package systemd - 237-3ubuntu10.45

---------------
systemd (237-3ubuntu10.45) bionic; urgency=medium

  [ Ioanna Alifieraki ]
  * d/p/lp1911187-systemctl-do-not-shutdown-immediately-on-scheduled-shutdo.patch:
    Do not shutdown immediately when scheduled shutdown fails (LP: #1911187)
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=257135a59455f4e4063e78cdd3f5cfeca2597b5b

  [ Dimitri John Ledkov ]
  * d/p/lp1878969-meson-initialize-time-epoch-to-reproducible-builds-compat.patch:
    meson: initialize time-epoch to reproducible builds compatible value
    (LP: #1878969)
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=6f5a0c94ff4a486ee0b72af926672b24d16ff5a8

  [ Dan Streetman ]
  * d/p/lp1913189-test-accept-that-char-device-0-0-can-now-be-created-.patch:
    - Fix failing test case under 5.8 kernel (LP: #1913189)
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=15143ec6cd584a18866390a042348a543e5aa22d
  * d/p/lp1913423-hashmap-make-sure-to-initialize-shared-hash-key-atom.patch:
    Thread-safe init of hashmap shared key (LP: #1913423)
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=95c189adb9c3e22576b26b084c7edf001cbc8307
  * d/p/lp1890448-hwdb-Add-EliteBook-to-use-micmute-hotkey.patch:
    Add EliteBook to use micmute hotkey (LP: #1890448)
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=19b48bdac5129aa772fbcd2dbf8d1bb5c30c1510
  * d/p/debian/patches/lp1902553-test-disable-QEMU-based-testing-for-TEST-16-EXTEND-T.patch:
    Disable TEST-03 run under qemu (LP: #1902553)
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=4e37d20ec379d169cfd53088d0c3b4d7bb65d25b
  * d/p/debian/patches/lp1883447-seccomp-add-all-time64-syscalls.patch:
    Add *time64 syscalls (LP: #1883447)
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=a459492c67c5c5855b03daca4b44141705495376
  * d/p/lp1685754-pid1-by-default-make-user-units-inherit-their-umask-.patch:
    Inherit umask for --user processes (LP: #1685754)
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=00df8d0e76975594adb765182c587ef495262fe1
  * d/p/debian/patches/lp1880258-log-nxdomain-as-debug.patch:
    Change NXDOMAIN 'errors' to log level debug (LP: #1880258)
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=9684abed02669bfcf696763b887518cf54cd3f69
  * d/p/lp1913763-udev-rules-add-rule-to-create-dev-ptp_hyperv.patch:
    Create symlink for hyperv-provided ptp device (LP: #1913763)
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=ff2a9ed2ece6bbd86a3d57f42b26cb1a6ca2845a

 -- Ioanna Alifieraki <email address hidden> Tue, 23 Feb 2021 03:45:01 +0200

Changed in systemd (Ubuntu Bionic):
status: Fix Committed → Fix Released
Revision history for this message
Łukasz Zemczak (sil2100) wrote : Update Released

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.

Displaying first 40 and last 40 comments. View all 104 comments or add a comment.
This report contains Public Security information  
Everyone can see this security related information.

Other bug subscribers

Remote bug watches

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