As an aside, I feel like this is a bad user experience. Having to have the user both insert the smartcard and then confirm they inserted the smartcard is repetitive.  The system knows when a smartcard is inserted, so giving a good user experience is just a plumbing problem.  It should be possible to do this plumbing without busy-waiting or polling, though maybe it requires fixing the interface between sssd and pam_sss ?

PAM_TEXT_INFO messages should work fine. This is what pam_pkc11 does:

      if (login_token_name) {•
        sprintf(prompt,•
                _("Please insert your smart card called \"%.32s\"."),•
                login_token_name);•
        pam_prompt(pamh, PAM_TEXT_INFO, NULL, prompt);•
      } else {•
        pam_prompt(pamh, PAM_TEXT_INFO, NULL,•
                 _("Please insert your smart card."));•
      }•
...
      rv = wait_for_token(ph, configuration->slot_num,•
                          login_token_name, &slot_num);•

Anyway, regardless, we've regressed behavior from 7.3, so devack+ to mop the regression up.

I agree that the user experience can be improved here. But I also would like to try to use the resources efficiently.

Since gdm already waits for a Smartcard event my original idea was send the message to gdm with pam_prompt and then send a PAM return code which would have the same effect as the Cancel button so that gdm can continue waiting for a Smartcart to be inserted. But iirc I didn't found a suitable PAM return code for this.

About the interface between sssd and pam_sss, it is already possible to the send a request to SSSD and the waiting with poll() on the socket for a reply from SSSD. But so far didn't want to implement a waiting feature in SSSD's Smartcard component because the client (gdm) is already waiting on it. But of course this can be done as well.

(In reply to Sumit Bose from comment #3)

> Since gdm already waits for a Smartcard event my original idea was send the
> message to gdm with pam_prompt and then send a PAM return code which would
> have the same effect as the Cancel button so that gdm can continue waiting
> for a Smartcart to be inserted. But iirc I didn't found a suitable PAM
> return code for this.
well, actually GDM doesn't know about smartcard events at all really.  gnome-settings-daemon monitors smartcard state and exports it to the session, and gnome-shell uses that information to decide whether or not to ask GDM to start a smartcard authentication conversation (of course, depending on if it's an unlock screen or a login screen, gnome-shell may ask GDM to start a smartcard conversation in other cases too).

It would certainly be possible for gnome-shell to cancel the PAM conversation and start a fresh one when the user inserts a smartcard, but that's a bit of a hammer approach. It could lead to blinking messages and delays.  And remember, gnome-shell doesn't know exactly what smartcard is getting asked for.

> About the interface between sssd and pam_sss, it is already possible to the
> send a request to SSSD and the waiting with poll() on the socket for a reply
> from SSSD. But so far didn't want to implement a waiting feature in SSSD's
> Smartcard component because the client (gdm) is already waiting on it. But
> of course this can be done as well.
So SSSD isn't actively watching smartcard state at the moment?

(In reply to Ray Strode [halfline] from comment #4)

> And remember, gnome-shell doesn't know exactly what smartcard is
> getting asked for.
That's not really true I guess.  It knows what the login card is.

(In reply to Ray Strode [halfline] from comment #4)
> (In reply to Sumit Bose from comment #3)
> 

> > About the interface between sssd and pam_sss, it is already possible to the
> > send a request to SSSD and the waiting with poll() on the socket for a reply
> > from SSSD. But so far didn't want to implement a waiting feature in SSSD's
> > Smartcard component because the client (gdm) is already waiting on it. But
> > of course this can be done as well.
> So SSSD isn't actively watching smartcard state at the moment?

No, because I'm not sure if SSSD would be the right place. Maybe a DBus interface for pcscd would be more flexible? Maybe we should talk with other people like Bob, Nalin and Nikos what they think might be the best solution for this kind of service. If there is an agreement I won't mind implementing this as part of SSSD, but maybe pcscd itself or p11-kit might be good alternatives as well?

Btw, I came across another use case we have for accepting just hitting enter without entering anything else. In an environment where a single certificate can be mapped to multiple accounts (e.g. a personal account and an functional account like data base admin) SSSD can be configured to not only ask for the PIN but an optional "user name hint" to disambiguate the case where a certificate is mapped to multiple accounts. But a user who knows that his certificate is only mapped to a single account should be able to just skip the "user name hint". The same scheme is offered by AD this is why I use the term "user name hint" here as well.

Shall I ask out QE team to give QA_ACK+ to this ticket?

(In reply to Sumit Bose from comment #6)
> No, because I'm not sure if SSSD would be the right place.
Well, at the end of the day, I think anything that accesses smartcards should know when they're added and removed.  NSS provides an API to be told that information (SECMOD_WaitForAnyTokenEvent) which is what pam_pkcs11 and gnome-settings-daemon use.  I guess you could just use that too?

> Maybe a DBus interface for pcscd would be more flexible? 
I don't think it's necessarily true that all security tokens use pcscd.

> Btw, I came across another use case we have for accepting just hitting enter
> without entering anything else. In an environment where a single certificate
> can be mapped to multiple accounts (e.g. a personal account and an
> functional account like data base admin) SSSD can be configured to not only
> ask for the PIN but an optional "user name hint" to disambiguate the case
> where a certificate is mapped to multiple accounts. But a user who knows
> that his certificate is only mapped to a single account should be able to
> just skip the "user name hint". The same scheme is offered by AD this is why
> I use the term "user name hint" here as well.
why doesn't pam_sss check that the certificate only maps to one user account and just skip asking the question?

> Shall I ask out QE team to give QA_ACK+ to this ticket?
sure.

(In reply to Ray Strode [halfline] from comment #7)
> (In reply to Sumit Bose from comment #6)
...
> why doesn't pam_sss check that the certificate only maps to one user account
> and just skip asking the question?
> 

This would of course be possible but we were asked to do it like AD which has the optional user name prompt as can be seen e.g. in https://sbose.fedorapeople.org/sc/AD_SC_auth_2users.webm e.g. around time 4:20.

okay, that seems like a suboptimal user experience, but I guess it's neither here nor there.  we just need to fix mutter to support it regardless.

[root@dhcp129-184 ~]# rpm -qi gnome-shell
Name        : gnome-shell
Version     : 3.22.3
Release     : 16.el7
Architecture: x86_64
Install Date: Mon 26 Jun 2017 07:50:42 AM MDT
Group       : User Interface/Desktops
Size        : 10177850
License     : GPLv2+
Signature   : (none)
Source RPM  : gnome-shell-3.22.3-16.el7.src.rpm
Build Date  : Thu 15 Jun 2017 08:58:11 AM MDT
Build Host  : x86-030.build.eng.bos.redhat.com
Relocations : (not relocatable)
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
Vendor      : Red Hat, Inc.
URL         : https://wiki.gnome.org/Projects/GnomeShell
Summary     : Window management and application launching for GNOME

After the required smartcard is entered and enter is pressed, the smartcard pin is prompted for.

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-2017:2098