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):
Steps to Reproduce:
1. Enable Smartcard authentication and Screen lock on smartcard removal options in authconfig UI
2. Login using smartcard
Screen locks soon after login
Should take to the desktop screen soon after login
can you try the same steps in a fresh 7.4 install and confirm the problem doesn't happen in that release?
(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
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
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.
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.
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.
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.
roshni can you quack?
Could you ask someone from Desktop QE to ACK?
i guess so, but you usually ack smartcard bugs and you filed this one...
tpelka do you mind?
(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.
Yes I can verify this bug.
(In reply to Roshni from comment #18)
> Yes I can verify this bug.
Thanks please go ahead.
[root@dhcp129-188 nssdb]# rpm -qi gnome-settings-daemon
Name : gnome-settings-daemon
Version : 3.26.2
Release : 8.el7
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.
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.