Activity log for bug #1782152

Date Who What changed Old value New value Message
2018-07-17 13:09:22 Dariusz Gadomski bug added bug
2018-07-17 13:11:17 Dariusz Gadomski description In case of the following scenario: 1. PAM configured to run auth and session 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. 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.
2018-07-17 14:28:15 Dariusz Gadomski 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. 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.
2018-07-17 14:29:22 Dariusz Gadomski attachment added auth.py https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/1782152/+attachment/5164561/+files/auth.py
2018-07-17 14:29:33 Dariusz Gadomski attachment added session.py https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/1782152/+attachment/5164562/+files/session.py
2018-07-17 14:33:33 Dariusz Gadomski summary GDM block SIGUSR1 used in PAM scripts GDM blocks SIGUSR1 used in PAM scripts
2018-07-18 01:52:21 Daniel van Vugt gdm (Ubuntu): status New Incomplete
2018-07-18 06:22:46 Daniel van Vugt tags bionic
2018-07-18 06:22:49 Daniel van Vugt gdm (Ubuntu): status Incomplete New
2018-07-18 06:22:55 Daniel van Vugt affects gdm (Ubuntu) gdm3 (Ubuntu)
2018-07-18 06:40:37 Daniel van Vugt gdm3 (Ubuntu): status New Incomplete
2018-07-18 13:17:17 Fabio B bug added subscriber Fabio Bardella
2018-07-18 14:45:05 Dariusz Gadomski attachment removed auth.py https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1782152/+attachment/5164561/+files/auth.py
2018-07-18 14:45:12 Dariusz Gadomski attachment removed session.py https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1782152/+attachment/5164562/+files/session.py
2018-07-18 14:45:33 Dariusz Gadomski attachment added auth.py https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1782152/+attachment/5164918/+files/auth.py
2018-07-18 14:45:46 Dariusz Gadomski attachment added session.py https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1782152/+attachment/5164919/+files/session.py
2018-07-19 01:42:11 Daniel van Vugt gdm3 (Ubuntu): status Incomplete New
2018-07-19 01:42:23 Daniel van Vugt 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. https://gitlab.gnome.org/GNOME/gdm/issues/399 --- 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.
2018-07-19 01:43:26 Daniel van Vugt gdm3 (Ubuntu): status New Confirmed
2018-07-23 12:17:32 Dariusz Gadomski attachment added cosmic_gdm3_3.28.2-3ubuntu2.debdiff https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1782152/+attachment/5166667/+files/cosmic_gdm3_3.28.2-3ubuntu2.debdiff
2018-07-23 12:17:57 Dariusz Gadomski attachment 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
2018-07-23 12:22:37 Dariusz Gadomski description https://gitlab.gnome.org/GNOME/gdm/issues/399 --- 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. 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.
2018-07-23 12:22:53 Dariusz Gadomski bug added subscriber STS Sponsors
2018-07-23 12:23:02 Dariusz Gadomski bug added subscriber Ubuntu Sponsors Team
2018-07-23 12:23:11 Dariusz Gadomski bug added subscriber Ubuntu Stable Release Updates Team
2018-07-23 12:23:57 Dariusz Gadomski 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. [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. 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.
2018-07-23 12:45:23 Dariusz Gadomski attachment added xenial_gdm3_3.18.3-0ubuntu2.2.debdiff https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1782152/+attachment/5166679/+files/xenial_gdm3_3.18.3-0ubuntu2.2.debdiff
2018-07-23 12:46:09 Dariusz Gadomski nominated for series Ubuntu Bionic
2018-07-23 12:46:09 Dariusz Gadomski nominated for series Ubuntu Cosmic
2018-07-23 12:46:09 Dariusz Gadomski nominated for series Ubuntu Xenial
2018-07-24 01:11:26 Daniel van Vugt gdm3 (Ubuntu): assignee Dariusz Gadomski (dgadomski)
2018-07-24 01:11:30 Daniel van Vugt gdm3 (Ubuntu): status Confirmed In Progress
2018-07-24 01:11:33 Daniel van Vugt gdm3 (Ubuntu): importance Undecided Medium
2018-07-30 13:58:40 Eric Desrochers bug task added gdm3 (Ubuntu Bionic)
2018-07-30 13:58:45 Eric Desrochers bug task added gdm3 (Ubuntu Cosmic)
2018-07-30 13:58:50 Eric Desrochers bug task added gdm3 (Ubuntu Xenial)
2018-08-02 13:43:42 Dariusz Gadomski bug watch added https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905277
2018-08-02 13:43:42 Dariusz Gadomski bug task added gdm3 (Debian)
2018-08-02 15:16:30 Bug Watch Updater gdm3 (Debian): status Unknown New
2018-08-02 16:42:25 Launchpad Janitor gdm3 (Ubuntu Cosmic): status In Progress Fix Released
2018-08-05 21:30:09 Bug Watch Updater gdm3 (Debian): status New Fix Released
2018-08-13 13:04:49 Launchpad Janitor merge proposal linked https://code.launchpad.net/~dgadomski/ubuntu/+source/gdm3/+git/lp1782152/+merge/352973
2018-08-13 13:11:35 Launchpad Janitor merge proposal linked https://code.launchpad.net/~dgadomski/ubuntu/+source/gdm3/+git/lp1782152/+merge/352976
2018-08-14 13:53:29 Eric Desrochers gdm3 (Ubuntu Bionic): status New In Progress
2018-08-14 13:53:33 Eric Desrochers gdm3 (Ubuntu Bionic): importance Undecided Medium
2018-08-14 13:53:44 Eric Desrochers gdm3 (Ubuntu Bionic): assignee Dariusz Gadomski (dgadomski)
2018-08-14 14:03:31 Sebastien Bacher gdm3 (Ubuntu Xenial): assignee Dariusz Gadomski (dgadomski)
2018-08-14 14:06:58 Launchpad Janitor merge proposal linked https://code.launchpad.net/~dgadomski/ubuntu/+source/gdm3/+git/lp1782152/+merge/353089
2018-08-17 13:46:03 Eric Desrochers gdm3 (Ubuntu Xenial): status New In Progress
2018-08-17 13:46:34 Eric Desrochers gdm3 (Ubuntu Xenial): importance Undecided Medium
2018-08-17 13:47:24 Eric Desrochers bug added subscriber Eric Desrochers
2018-08-17 13:47:29 Eric Desrochers removed subscriber STS Sponsors
2018-08-20 14:40:37 Łukasz Zemczak gdm3 (Ubuntu Bionic): status In Progress Fix Committed
2018-08-20 14:40:41 Łukasz Zemczak bug added subscriber SRU Verification
2018-08-20 14:40:43 Łukasz Zemczak tags bionic bionic verification-needed verification-needed-bionic
2018-08-20 14:47:55 Łukasz Zemczak removed subscriber Ubuntu Sponsors Team
2018-08-21 12:24:54 Łukasz Zemczak gdm3 (Ubuntu Xenial): status In Progress Fix Committed
2018-08-21 12:24:58 Łukasz Zemczak tags bionic verification-needed verification-needed-bionic bionic verification-needed verification-needed-bionic verification-needed-xenial
2018-08-21 13:33:38 Dariusz Gadomski tags bionic verification-needed verification-needed-bionic verification-needed-xenial bionic verification-done-bionic verification-needed verification-needed-xenial
2018-08-22 09:53:17 Dariusz Gadomski tags bionic verification-done-bionic verification-needed verification-needed-xenial bionic verification-done verification-done-bionic verification-done-xenial
2018-09-27 16:08:52 Launchpad Janitor gdm3 (Ubuntu Xenial): status Fix Committed Fix Released
2018-09-27 16:08:56 Brian Murray removed subscriber Ubuntu Stable Release Updates Team
2018-09-27 16:09:14 Launchpad Janitor gdm3 (Ubuntu Bionic): status Fix Committed Fix Released
2018-09-27 16:09:14 Launchpad Janitor cve linked 2018-14424