Bug 1693060

Summary: XDMCP remote session cannot unlock screen
Product: Red Hat Enterprise Linux 7 Reporter: Yuki Okada <yuokada>
Component: gdmAssignee: Ray Strode [halfline] <rstrode>
Status: CLOSED ERRATA QA Contact: Desktop QE <desktop-qa-list>
Severity: unspecified Docs Contact:
Priority: high    
Version: 7.6CC: alanm, amike, jwright, mboisver, mclasen, tpelka
Target Milestone: rcKeywords: Regression, ZStream
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: 7.1 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1693967 (view as bug list) Environment:
Last Closed: 2019-08-06 12:38:30 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1693967    

Description Yuki Okada 2019-03-27 04:12:31 UTC 
Description of problem:
Unlocking screen fails without error if the session is connected via XDMCP.

Version-Release number of selected component (if applicable):
gdm-3.28.2-12.el7_6.x86_64
systemd-219-62.el7_6.5.x86_64

How reproducible:
always

Steps to Reproduce:
1. Install RHEL 7.6 with GUI
2. Edit /etc/gdm/custom.conf as follows

  [security]
  DisallowTCP=false
  
  [xdmcp]
  Enable=true

3. Restart gdm to reflect the change

  # systemctl restart gdm.service

4. Connect to the server using Xephyr

  $ Xephyr -query <IP_address> :<display_number>

5. If polkit banner is displayed, click "cancel"
6. Choose user, enter password, and click "Sign in" (Login succeeds)
7. Lock the Xephyr session screen using a lock icon on top right corner
8. Enter password and click "unlock" button (This fails without error, and unable to unlock the screen)

Actual results:
Unlocking screen silently fails

Expected results:
Unlocking screen succeeds even if it's a XDMCP session

Additional info:
- If wrong password is entered, the message "Sorry, that didn't work. Please try again" appears under the password box.
- Clicking "Log in as another user" also silently fails.
- Unlocking screen on a local console works as expected, so this issue seems a remote session (XDMCP) specific issue.
- In RHEL 7.5 (gdm-3.26.2.1-5.el7.x86_64), Unlocking screen works normally even in a XDMCP session. So this might be a regression.
Comment 2 Yuki Okada 2019-03-27 04:16:12 UTC 
From gdm debug log during unlocking a screen, "GdmManager: unable to activate existing sessions unless on seat0" is logged and "Unlocking session" is NOT logged when the problem occurs.

- XDMCP session on RHEL 7.6 (gdm-3.28.2-12.el7_6.x86_64)
Mar 26 17:33:39 localhost.localdomain gdm[8440]: GdmSession: Emitting 'reauthenticated' signal
Mar 26 17:33:39 localhost.localdomain gdm[8440]: GdmSession: type (null), program? no, seat (null)
Mar 26 17:33:39 localhost.localdomain gdm[8440]: Failed to determine sessions: No such file or directory
Mar 26 17:33:39 localhost.localdomain gdm[8440]: GdmManager: unable to activate existing sessions unless on seat0  <<<-------
Mar 26 17:33:39 localhost.localdomain dbus[2988]: [system] Activating via systemd: service name='net.reactivated.Fprint' unit='fprintd.service'
Mar 26 17:33:39 localhost.localdomain gdm[8440]: GdmManager: trying to open reauthentication channel for user yuokada

- local console on RHEL 7.6 (gdm-3.28.2-12.el7_6.x86_64)
Mar 26 17:36:05 localhost.localdomain gdm[8440]: GdmSession: Emitting 'reauthenticated' signal
Mar 26 17:36:05 localhost.localdomain gdm[8440]: GdmSession: type (null), program? no, seat seat0
Mar 26 17:36:05 localhost.localdomain gdm[8440]: Unlocking session 11  <<<-------
Mar 26 17:36:05 localhost.localdomain dbus[2988]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service'
Mar 26 17:36:05 localhost.localdomain systemd[1]: Starting Hostname Service...
Mar 26 17:36:05 localhost.localdomain dbus[2988]: [system] Successfully activated service 'org.freedesktop.hostname1'
Mar 26 17:36:05 localhost.localdomain systemd[1]: Started Hostname Service.

- XDMCP session on RHEL 7.5 (gdm-3.26.2.1-5.el7.x86_64)
Mar 26 17:52:01 localhost.localdomain gdm[14029]: GdmSession: Emitting 'reauthenticated' signal
Mar 26 17:52:01 localhost.localdomain gdm[14029]: GdmSession: type (null), program? no, seat (null)
Mar 26 17:52:01 localhost.localdomain gdm[14029]: Failed to determine sessions: No such file or directory
Mar 26 17:52:01 localhost.localdomain gdm[14029]: Unlocking session 818  <<<-------
Mar 26 17:52:01 localhost.localdomain dbus[764]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service'
Mar 26 17:52:01 localhost.localdomain systemd[1]: Starting Hostname Service...
Mar 26 17:52:01 localhost.localdomain dbus[764]: [system] Successfully activated service 'org.freedesktop.hostname1'
Mar 26 17:52:01 localhost.localdomain systemd[1]: Started Hostname Service.

The debug message "GdmManager: unable to activate existing sessions unless on seat0" is introduced in the patch in BZ#1679914.

+        if (!seat_id || !sd_seat_can_multi_session (seat_id)) {
+                g_debug ("GdmManager: unable to activate existing sessions unless on seat0");
+                goto out;
+        }

I'm not really sure how XDMCP remote session should behave when unlocking a screen, but I think it would be good if session_unlock is called even if seat_id is null.
Comment 11 errata-xmlrpc 2019-08-06 12:38:30 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:2044