[Bug 1782152] Re: GDM blocks SIGUSR1 used in PAM scripts

[Łukasz Zemczak]

Hello Dariusz, or anyone else affected,

Accepted gdm3 into bionic-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/gdm3/3.28.3-0ubuntu18.04.1 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 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!

** Changed in: gdm3 (Ubuntu Bionic)
       Status: In Progress => Fix Committed

** Tags added: verification-needed verification-needed-bionic

-- 
You received this bug notification because you are a member of Ubuntu
Sponsors Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1782152

Title:
  GDM blocks SIGUSR1 used in PAM scripts

Status in gdm3 package in Ubuntu:
  Fix Released
Status in gdm3 source package in Xenial:
  In Progress
Status in gdm3 source package in Bionic:
  Fix Committed
Status in gdm3 source package in Cosmic:
  Fix Released
Status in gdm3 package in Debian:
  Fix Released

Bug description:
  https://gitlab.gnome.org/GNOME/gdm/issues/399

  [Impact]
  GDM blocks SIGUSR1 for it's processes, since this is used in communication with X. This signal is later unblocked, however it happens after PAM
  interaction, so if PAM depends on this signal in any way it will get blocked.
  The issue has been fixed upstream.

  [Test Case]
  1. Prepare a setup described in Other Info using the attached scripts.
  2. Log in.
  3. Check logs /tmp/auth.log.

  Expected result: SIGUSR1 has been received.
  Actual result: SIGUSR1 never reaches the process.

  [Regression Potential]
  If there were components depending on SIGUSR1 their behavior may change - features that were inactive before may be triggered.

  [Other Info]

   Original bug description:

  In case of the following scenario:
  1. PAM configured to run auth and session with pam_exec scripts synchronizing via SIGUSR1
  2. Using GDM as the login manager causes SIGUSR1 never reaches the target scripts.

  Workaround:
  a) Use SIGUSR2 in the scripts.
  b) Comment out block_sigusr1() call in daemon/main.c.

  To reproduce add the following entries:
  /etc/pam.d/common-auth:
  auth	optional	pam_exec.so log=/tmp/auth.log expose_authtok quiet /usr/local/bin/auth.py

  /etc/pam.d/common-session:
  session	optional  pam_exec.so   log=/tmp/session.log  /usr/local/bin/session.py

  Attaching example scripts.
  When using SIGUSR1 - sigusr1_handler is never called, with SIGUSR2 it is called without issues.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1782152/+subscriptions