Bug 1532820 - Screen locks soon after smartcard login
Screen locks soon after smartcard login
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: gnome-settings-daemon (Show other bugs)
7.5
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Ray Strode [halfline]
Desktop QE
https://gitlab.gnome.org/GNOME/gnome-...
: OtherQA, Regression
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2018-01-09 15:46 EST by Roshni
Modified: 2018-05-17 10:39 EDT (History)
5 users (show)

See Also:
Fixed In Version: gnome-settings-daemon-3.26.2-8.el7
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2018-04-10 09:10:18 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
/var/log/messages during screen lock (22.61 KB, text/plain)
2018-01-09 15:46 EST, Roshni
no flags Details
smartcard: Wait until smartcards are inspected before locking screen (12.16 KB, patch)
2018-02-09 16:48 EST, Ray Strode [halfline]
no flags Details | Diff
smartcard: handle a smartcard getting removed very shortly after login (14.82 KB, patch)
2018-02-09 16:48 EST, Ray Strode [halfline]
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:0770 None None None 2018-04-10 09:11 EDT

  None (edit)
Description Roshni 2018-01-09 15:46:44 EST
Created attachment 1379243 [details]
/var/log/messages during screen lock

Description of problem:
Screen locks soon after smartcard login

Version-Release number of selected component (if applicable):
gnome-session-3.26.1-8.el7.x86_64

How reproducible:
always

Steps to Reproduce:
1. Enable Smartcard authentication and Screen lock on smartcard removal options in authconfig UI
2. Login using smartcard
3.

Actual results:
Screen locks soon after login

Expected results:
Should take to the desktop screen soon after login

Additional info:
Attaching /var/log/messages
Comment 3 Ray Strode [halfline] 2018-01-09 15:54:36 EST
can you try the same steps in a fresh 7.4 install and confirm the problem doesn't happen in that release?
Comment 4 Roshni 2018-01-09 16:52:48 EST
(In reply to Ray Strode [halfline] from comment #3)
> can you try the same steps in a fresh 7.4 install and confirm the problem
> doesn't happen in that release?

I do not see this issue on RHEL 7.4
Comment 5 Roshni 2018-01-12 09:24:59 EST
https://bugzilla.redhat.com/show_bug.cgi?id=1450176 was a similar is a similar bug that was detected and fixed in RHEL 7.4
Comment 6 adam winberg 2018-01-26 01:57:33 EST
I'm seeing this in 7.5 beta, but I also had it in 7.4. In 7.4 it started quite recently, in the last couple of weeks or so, running gnome-shell-3.22.3-17.

I haven't had any relevant updates on my machine except the meltdown/spectre patches, so I don't know what made the issue arise so suddenly. I can't really see in the logs either what causes it, so I can't pinpoint exactly when it started to happen.
Comment 7 adam winberg 2018-01-26 02:36:52 EST
I can add that I have colleagues that do not see this in 7.4, but in 7.5 it seems to happen to everyone.
Comment 12 Ray Strode [halfline] 2018-02-09 16:48 EST
Created attachment 1394005 [details]
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.
Comment 13 Ray Strode [halfline] 2018-02-09 16:48 EST
Created attachment 1394007 [details]
smartcard: handle a smartcard getting removed very  shortly after login

Right now we depend on the smartcard used at login time to be inserted,
at least long enough to read some basic stats about it.  This
assumption, of course doesn't necessarly need to hold true.  A user
could remove the smartcard immediately after login and we would
misreport that the card wasn't used for login at all.

This commit addresses that edge case by creating a login_token
smartcard alias object that's around even if the login token isn't.
Once the login token does show up it gets synchronized with it, so
both object paths refer to the same underlying token.
Comment 14 Ray Strode [halfline] 2018-02-09 16:50:15 EST
roshni can you quack?
Comment 15 Roshni 2018-02-09 17:01:28 EST
Could you ask someone from Desktop QE to ACK?
Comment 16 Ray Strode [halfline] 2018-02-10 09:40:17 EST
i guess so, but you usually ack smartcard bugs and you filed this one...

tpelka do you mind?
Comment 17 Tomas Pelka 2018-02-10 09:57:36 EST
(In reply to Ray Strode [halfline] from comment #16)
> i guess so, but you usually ack smartcard bugs and you filed this one...
> 
> tpelka do you mind?

Ack, assuming Roshni will verify.
Comment 18 Roshni 2018-02-12 10:15:33 EST
Yes I can verify this bug.
Comment 20 Tomas Pelka 2018-02-13 02:17:38 EST
(In reply to Roshni from comment #18)
> Yes I can verify this bug.

Thanks please go ahead.
Comment 21 Roshni 2018-02-13 12:03:54 EST
[root@dhcp129-188 nssdb]# rpm -qi gnome-settings-daemon
Name        : gnome-settings-daemon
Version     : 3.26.2
Release     : 8.el7
Architecture: x86_64
Install Date: Mon 12 Feb 2018 03:39:19 PM EST
Group       : Unspecified
Size        : 5409618
License     : GPLv2+
Signature   : (none)
Source RPM  : gnome-settings-daemon-3.26.2-8.el7.src.rpm
Build Date  : Mon 12 Feb 2018 12:21:54 PM EST
Build Host  : x86-040.build.eng.bos.redhat.com
Relocations : (not relocatable)
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
Vendor      : Red Hat, Inc.
URL         : https://download.gnome.org/sources/gnome-settings-daemon
Summary     : The daemon sharing settings from GNOME to GTK+/KDE applications

I do not see the issue in the bug description with this build.
Comment 24 errata-xmlrpc 2018-04-10 09:10:18 EDT
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-2018:0770

Note You need to log in before you can comment on or make changes to this bug.