SRU proposal for Bionic. ** Patch added: "bionic_gdm3_3.28.2-0ubuntu1.4.debdiff" https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1782152/+attachment/5166668/+files/bionic_gdm3_3.28.2-0ubuntu1.4.debdiff
** Description changed: 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. + + [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. ** Description changed: 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: + + 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. -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gdm3 in Ubuntu. https://bugs.launchpad.net/bugs/1782152 Title: GDM blocks SIGUSR1 used in PAM scripts To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1782152/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
