Bug 1674382
| Summary: | Gnome session locks after login | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | tfolinux | ||||||
| Component: | gnome-settings-daemon | Assignee: | Ray Strode [halfline] <rstrode> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | Desktop QE <desktop-qa-list> | ||||||
| Severity: | unspecified | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 8.0 | CC: | adam.winberg, cpippin, dkochuka, eric.soderman, grajaiya, hdegoede, jhrozek, jkoten, lslebodn, mboisver, mzidek, pbrezina, rpattath, rstrode, sbose, tpelka, tscherf | ||||||
| Target Milestone: | rc | Keywords: | OtherQA | ||||||
| Target Release: | 8.0 | Flags: | pm-rhel:
mirror+
|
||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | gnome-settings-daemon-3.32.0-2.el8 | Doc Type: | If docs needed, set a value | ||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2019-11-05 22:13:35 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: | |||||||||
| Attachments: |
|
||||||||
Just tried to use password auth instead of smartcard and that works as expected, so this seems to be a smartcard specific thing. With RHEL-8 your user-session will be running on VT2. So the reason you are getting the unlock screen when you switch to VT1 is because you are switching back to VT1, try switching to VT2 instead. This will not fix the issue with the initial login, but it should help with the "if I change VT and then change back to gnome (ALT+F1)" case. Ah yes, you're correct. I missed that. But why is there a GDM login session running on VT1, that's just confusing..? (bit offtopic here) (In reply to tfolinux from comment #3) > Ah yes, you're correct. I missed that. But why is there a GDM login session > running on VT1, that's just confusing..? (bit offtopic here) Because the X-server now runs as the user for which the session is started, rather then as root (for security reasons), so a separate X-server is started for the user-session on the first free VT. Ok, thanks for info! I can also add that when using password auth the files in /var/lib/AccountsService/users/ are created correctly (when using smartcard auth they are not created at all) (OP here, but with another account) When I login with smartcard, the $USERNAME/$USER env var is set to 'username.com', it should be just 'username'. So it seems that sssd passes the wrong data to pam in this regard. AccountsService may not accept that type of username? Can i set something in sssd.conf to get sssd to pass on the 'correct' username to PAM? I've tried setting 'default_domain_suffix' and 'full_name_format', but no change in behaviour regarding $USERNAME. Not much activity here - i'll add some sssd debug logs and hope for some attention. When I login (in gdm, with smartcard + PIN) pam outputs: gdm-smartcard][3821]: pam_sss(gdm-smartcard:auth): authentication success; logname= uid=0 euid=0 tty=/dev/tty1 ruser= rhost= user=a001329.com gdm-smartcard][3821]: pam_unix(gdm-smartcard:session): session opened for user a001329.com by (uid=0) Notice the username format for my user (a001329). My gnome session is immediately locked. When I unlock it (with smartcard + PIN) pam outputs: gdm-smartcard][3680]: pam_sss(gdm-smartcard:auth): authentication success; logname= uid=0 euid=0 tty=/dev/tty2 ruser= rhost= user=a001329 Notice that the 'user' attribute has changed. Don't know if this is at all relevant though... Created attachment 1541399 [details]
sssd debug logs
Debug logs from GDM login (not including gnome session unlock)
can you post the output of $ env run from a terminal with in a session that was logged in the smart card ? In particular I'm interested in the value of the PKSC11_LOGIN_TOKEN_NAME environment variable. Also, does changing the value of use_fully_qualified_names in sssd.conf affect this bug? Adam is on vacation so I will answer instead. Here is env: XDG_MENU_PREFIX=gnome- LANG=en_GB.UTF-8 GDM_LANG=en_GB.UTF-8 DISPLAY=:1 HISTTIMEFORMAT=%F %T COLORTERM=truecolor USERNAME=a002107.com XDG_VTNR=2 SSH_AUTH_SOCK=/run/user/66212/keyring/ssh XDG_SESSION_ID=4 USER=a002107.com DESKTOP_SESSION=gnome GNOME_TERMINAL_SCREEN=/org/gnome/Terminal/screen/4850ff78_1cc3_4fe9_8652_fd70bc82e162 PWD=/home/a002107 HOME=/home/a002107 XDG_SESSION_TYPE=x11 KRB5CCNAME=KEYRING:persistent:66212 XDG_DATA_DIRS=/home/a002107/.local/share/flatpak/exports/share/:/var/lib/flatpak/exports/share/:/usr/local/share/:/usr/share/ XDG_SESSION_DESKTOP=gnome GJS_DEBUG_OUTPUT=stderr PKCS11_LOGIN_TOKEN_NAME=identification (Instant EID IP9) WINDOWPATH=2 SHELL=/bin/bash TERM=xterm-256color VTE_VERSION=5202 QT_IM_MODULE=ibus XMODIFIERS=@im=ibus XDG_CURRENT_DESKTOP=GNOME GNOME_TERMINAL_SERVICE=:1.80 XDG_SEAT=seat0 SHLVL=1 MANPATH=:/opt/puppetlabs/puppet/share/man GDMSESSION=gnome GNOME_DESKTOP_SESSION_ID=this-is-deprecated LOGNAME=a002107.com DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/66212/bus XDG_RUNTIME_DIR=/run/user/66212 XAUTHORITY=/run/user/66212/gdm/Xauthority PATH=/home/a002107/.local/bin:/home/a002107/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/opt/puppetlabs/bin GJS_DEBUG_TOPICS=JS ERROR;JS LOG SESSION_MANAGER=local/unix:@/tmp/.ICE-unix/12875,unix/unix:/tmp/.ICE-unix/12875 LESSOPEN=||/usr/bin/lesspipe.sh %s _=/usr/bin/env I will try use_fully_qualified_names on friday when I am back at work. Man page says it is default false and we have not set it. great thanks, can you also provide the output of certutil -L -d /etc/pki/nssdb -h all ? i wonder if this is a case where the token name changes depending on whether or not a pin code is used. Here is certutil -L -d /etc/pki/nssdb -h all
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
Enter Password or Pin for "identification (Instant EID IP9)":
identification (Instant EID IP9):a002107 u,u,u
identification (Instant EID IP9):erso.adm u,u,u
I have also tried use_fully_qualified_names, both True and False. No changes in behaviour with locking after login and $USERNAME.
okay so to me, it looks like perhaps, pam_sss is setting PKCS11_LOGIN_TOKEN_NAME to the slot name instead of the token name, reassigning to sssd Upon closer inspection, it appears that I misread the output in comment 13. Reassigning to gnome-settings-daemon *** Bug 1643255 has been marked as a duplicate of this bug. *** So the problem is actually just a missing patch. In RHEL 7 we have this patch: From 0665bd86221d3c9012f0391d8e4939a2d12b6417 Mon Sep 17 00:00:00 2001• From: Ray Strode <rstrode>• Date: Fri, 9 Feb 2018 16:39:12 -0500• Subject: [PATCH 1/2] smartcard: Wait until smartcards are inspected before• locking screen• • There's a race condition in the code where we check if the screen should• be locked (because the smartcard is removed) before we necessarly check• the smartcard's insertion status.• • This commit fixes the race by iterating through all smartcards at• startup and checking their status explicitly.• ---• plugins/smartcard/gsd-smartcard-manager.c | 61 ++++++++++++++++++-----• 1 file changed, 49 insertions(+), 12 deletions(-)• but it's missing from RHEL 8. So RHEL8.0 is released but this bug is still present. When is it expected to be resolved? Is there any workarounds? This bug is currently, tentatively slated to be fixed in 8.1. I don't know of any workaround at this time. Could I install the version from RHEL7 instead? Practically speaking, that may work, but it's not something that's supported. Deepu, can you pass the build from the errata on to the customer to test in their environment? (In reply to Ray Strode [halfline] from comment #32) > Deepu, can you pass the build from the errata on to the customer to test in > their environment? Any feedback here? 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/RHSA-2019:3553 |
Created attachment 1528900 [details] GDM debug log Description of problem: Logging in with GDM with smartcard causes my gnome session to immediately lock (as in lockscreen, not as in freeze). I then can authenticate again in GDM to unlock and then everything seems to work. However, if I change VT and then change back to gnome (ALT+F1), my session is again locked and I have to login again. Looking at the logs it seems like GDM for some reason switches VT (different XDG_VTNR when issue arise), which may trigger the bug (?) that causes the gnome session to lock. Another problem that may or may not be related is that there is no user configuration saved for AccountsService - the /var/lib/AccountsService/users directory is empty. Following log line may be relevant: gdm-smartcard][2623]: could not save session and language settings I've tried this with Wayland and with 'WaylandEnable=false' in gdm's custom.conf, same result. I've also ruled out SELinux as a cause. And I've tried with both modesetting and intel X drivers. Version-Release number of selected component (if applicable): gdm-3.28.3-9.el8.x86_64 How reproducible: Always Steps to Reproduce: 1. Login in GDM to gnome session 2. 3. Actual results: Gnome session starts, desktop is briefly shown but session then locks. Expected results: Session should not lock. Additional info: Attaching gdm logs with debug enabled.