Bug 2140898

Hi,

does it work for you in RHEL8.6+?

Yes, it works in RHEL8.6+

(In reply to adam winberg from comment #2)
> Yes, it works in RHEL8.6+

This probably points to GDM (is this GDM use case?) because SSSD package is practically the same on 8.6 and 9.0...

> This probably points to GDM (is this GDM use case?)
Correct, this is GDM

Hi Adam,

I'm trying to reproduce your issue on RHEL8.6 and I'm unable to so far.  GDM prompts with a message to "Please insert smart card" at the login screen.  At screenlock I see "Please insert smart card labeled <my card label>".

Is that what you're seeing when the smart card is not inserted?

Can you give me some details about your setup?  sssd.conf, authselect command used, pam custom changes?  Is this an IPA/IdM client or a stand alone system?

In my test, I setup sssd.conf like this:

# cat /etc/sssd/sssd.conf
[sssd]
debug_level = 9
services = nss, pam
domains = shadowutils

[nss]
debug_level = 9

[pam]
debug_level = 9
pam_cert_auth = True

[domain/shadowutils]
debug_level = 9
id_provider = files

[certmap/shadowutils/testuser]
debug_level = 9
matchrule = <SUBJECT>.*CN=testuser.*


I initially set authselect with-smartcard only.  I added with-smartcard-required later.

# authselect select sssd with-smartcard

I configured my card and tested with su to make sure smart card authentication was working in general at the command line:

# su - testuser -c 'su - testuser -c whoami'
PIN for MyEID (sctest): 
testuser


Then I ran a gdm login test

# systemctl restart gdm

Insert card, prompted for PIN, login succeeded.

The I enabled with-smartcard-required feature:

# authselect enable-feature with-smartcard-required
Make sure that SSSD service is configured and enabled. See SSSD documentation for more information.

And just to see screen lock behavior, lock-on-removal as well:

# authselect enable-feature with-smartcard-lock-on-removal
Make sure that SSSD service is configured and enabled. See SSSD documentation for more information.

Then I completely reset SSSD and restarted GDM:

# systemctl stop sssd; rm -rf /var/lib/sss/{db,mc}/*; systemctl start sssd; systemctl restart gdm

Now when I either login or remove the smart card, I see the "Please insert smart card" message.   

I was thinking that was intentionally added by a bug fix in either SSSD or GDM.  This is one BZ I found:

https://bugzilla.redhat.com/show_bug.cgi?id=1645249


So any more information you can give us about your setup will help.

Thanks

> I'm trying to reproduce your issue on RHEL8.6 
This issue is reported against RHEL9. You can not reproduce it on RHEL8. 

> GDM prompts with a message to "Please insert smart card" at the login screen.  At screenlock I see "Please insert smart card labeled <my card label>". Is that what you're seeing when the smart card is not inserted?
Yes.

I am not sure about what you are trying to reproduce - the issue is that I no longer can input the PIN code before inserting the card, which I could do in RHEL8. 
Well, I am actually still able to type in PIN before inserting the smart card, but when I insert the card my PIN input is cleared and I am prompted for PIN code again.

(In reply to adam winberg from comment #6)
> 
> > GDM prompts with a message to "Please insert smart card" at the login screen.  At screenlock I see "Please insert smart card labeled <my card label>". Is that what you're seeing when the smart card is not inserted?
> Yes.

Is this message the same both on 8.6 and 9.0?
And you type PIN in response (but following behavior is different)?

> Is this message the same both on 8.6 and 9.0?
Yes, same message.

> And you type PIN in response (but following behavior is different)?
Actually, testing this a bit more thoroughly (it is mostly muscle memory otherwise when I do it) - when the 'Insert card' message is showing the pin input is disabled, so I can't type anything. And this was probably the same in RHEL8 as well. 
BUT when the clock is showing on the lock screen, or when the screen is asleep, it is possible to start typing to input PIN (plus press 'enter') before the 'insert card' message is showing (you need to be pretty fast though). This behaviour is also the same on RHEL8 and RHEL9. 
But in RHEL8 that PIN input was used to unlock when the card was inserted, while in RHEL9 it is not. 

A small thing maybe, but it makes the login process a lot faster and easier for me compared to having to insert card and wait for pin prompt before typing in PIN.

(In reply to adam winberg from comment #8)
> > Is this message the same both on 8.6 and 9.0?
> Yes, same message.
> 
> > And you type PIN in response (but following behavior is different)?
> Actually, testing this a bit more thoroughly (it is mostly muscle memory
> otherwise when I do it) - when the 'Insert card' message is showing the pin
> input is disabled, so I can't type anything. And this was probably the same
> in RHEL8 as well. 
> BUT when the clock is showing on the lock screen, or when the screen is
> asleep, it is possible to start typing to input PIN (plus press 'enter')
> before the 'insert card' message is showing (you need to be pretty fast
> though). This behaviour is also the same on RHEL8 and RHEL9. 
> But in RHEL8 that PIN input was used to unlock when the card was inserted,
> while in RHEL9 it is not. 

Ok, I think I'm able to see the same behavior now with my basic setup.

On RHEL8.6:

At the lock screen, typing the PIN on the clock screen without moving the mouse does enter it into the input field. If I then insert the card, the screen is unlocked.

On RHEL9.0:

At the lock screen, typing the PIN on the clock screen without moving the mouse does enter it into the input field.  However, when I insert the card, the screen is not unlocked.  Instead it clears the input field and prompts to enter the PIN.  If I enter it there, it does log in.

Ray, could you please take a look at this ticket and provide your opinion what is (or isn't) an expected behavior?

So for the login screen, i don't think it's expected to ask for a pin at all if the smartcard isn't inserted. It should say

"Please insert smart card"

with a desensitized prompt.

The unlock screen is a bit of a special case. We actually go out of our way to gather input typed while the clock is up, so password users can just come back, type their password and hit enter.

I think keeping that behavior for smartcard pin is reasonable, though it's not exactly as intuitively obvious that it should work.

I'm going to move this to gnome-shell where the feature would need to be readded. It's probably clearing the saved input on reset, and we'll need to keep it around a little longer if the foreground authentication method is smartcard.

Any plans of re-adding this 'feature'?

This bug is currently being evaluated for inclusion in a future Red Hat Enterprise Linux 9 update.

so what's happening is we now unconditionally reset the auth prompt when inserting a smartcard because of this commit:

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1999/diffs?commit_id=ceee53aa0a40f3bf81945fabb4ecdd70d11143a4

This commit below avoids the reset if the auth prompt is already visible:

I need to do a little more digging to make sure it doesn't regress the original commit, but I think it's probably okay.

diff --git a/js/ui/unlockDialog.js b/js/ui/unlockDialog.js
index 00e3eef..1e137a6 100644
--- a/js/ui/unlockDialog.js
+++ b/js/ui/unlockDialog.js
@@ -727,15 +727,15 @@ var UnlockDialog = GObject.registerClass({
             onComplete: () => this._maybeDestroyAuthPrompt(),
         });
     }
 
     _showPrompt() {
-        this._ensureAuthPrompt();
-
         if (this._activePage === this._promptBox)
             return;
 
+        this._ensureAuthPrompt();
+
         this._activePage = this._promptBox;
 
         this._adjustment.ease(1, {
             duration: CROSSFADE_TIME,
             mode: Clutter.AnimationMode.EASE_OUT_QUAD,

Actually there must be more to the story, since that commit didn't make it into Red Hat Enterprise Linux until last week.

I'll see if I can reproduce with an older version of gnome-shell that predates that commit and do a little more digging.

Created attachment 1964678 [details]
smartcard reset fix

ah I see, I was actually completely off base with comment 24.

The issue is here:

https://gitlab.gnome.org/GNOME/gnome-shell/-/commit/c8bb45b41c3a13ef161103f649aa18938e028a70

Basically, we have new verification state that the auth prompt can get set to after the user has interacted with the authentication prompt.

It's meant to be able to distinguish "user cancelled active authentication conversation" from "user hit escape without doing anything just to get back to clock"

The former case gets some rate limiting so the user can't just hit escape any time it looks like their password attempt is going to fail, just to quickly try again.

The smartcard detection logic avoids reseting the smartcard service if it thinks an authentication conversation is currently in progress, but that logic wasn't adapted to account for this new verification state.

The above attachment fixes it.

VERIFIED with gnome-shell-40.10-12.el9.x86_64 (also: gdm-40.1-21.el9.x86_64, sssd-2.9.0-3.el9.x86_64)

Verification is done using one system with certutil of nss tools for test certificates generation and virt-viewer/remote-viewer that exposes them them to the actual test VM as a virtual smartcart using Spice. The test CA cert is copied to the actual test system as: "/etc/sssd/pki/sssd_auth_ca_db.pem". Other configurations of the test system are:

* add a test user: useradd -G users -m test

* configure authselect as follows: authselect select sssd with-smartcard with-smartcard-lock-on-removal

* /etc/sssd/conf.d/sclogin.conf with permissions of 0600:
```
[sssd]
debug_level = 9
services = nss, pam
domains = sclogin
certificate_verification = no_ocsp

[nss]
homedir_substring = /home
override_homedir = /home/%u

[pam]
pam_cert_auth = True

[domain/sclogin]
debug_level = 9
id_provider = files

[certmap/sclogin/test]
matchrule = <KU>clientAuth,nonRepudiation
matchrule = <SUBJECT>.*UID=test.*
```

I'll post the script to create the certificates and how to invoke virt-viewer later.