Issue

+++ This bug was initially created as a clone of Bug #1936551 +++ Description of problem: When attempting to login via gdm or tty with a YubiKey smartcard with a blocked PIN, you simply get an authentication failure message. On Windows you get a helpful message indicating that the PIN is blocked. We should do the same. Version-Release number of selected component (if applicable): sssd-2.3.0-9.el8.x86_64 [...] — Additional comment from Ray Strode [halfline] on 2022-07-13 09:43:21 EDT — Just to summarize prior discussions, there are two issues at play here with the login screen: 1) Error messages preempt non-error messages. Since this message isn't presented as an error, it gets preempted. 2) Messages are shown proportional to their length. Since this message is only two short words long, it doesn't get displayed for very long. In the mailing list thread I suggested 1) Changing the error to be an error message 2) Making the error message less terse and more user friendly, "Smart card blocked by too many unsuccessful login attempts" Doing those two things would get it 90% there without any changes outside of the pam module. But, Sumit pointed out this could still be too short for languages that condense messages into a small number of characters (like say Japanese). This latter problem isn't specific to smartcard messages, of course, but a general gnome-shell problem. And, regardless, neither gnome-shell nor the pam module are in a vaccuum, they're pieces meant to fit together as well as possible, despite the poor abstraction between them, so making changes to gnome-shell to accommodate the smartcard service makes sense to me. My suggestion would be to make the two changes I wrote above, which I think are a good idea regardless, and to clone this bug against gnome-shell to have it get fixed to not preempt info messages for the smartcard service, and have it get fixed to add a minimum time for messages. Figuring out the exact timing is going to be a little tricky. People have filed bugs in the past about the messages taking too long, so we need to find a good middle ground. It's also tricky because it presumably takes longer for a japanese user to read each character than it takes say a spanish person to read each character. It's not immediately clear how we'll reconcile this, but a bug would be good for sure. I don't know if the bug will get fixed by 9.1 or not. [...] — Additional comment from Ray Strode [halfline] on 2022-07-13 13:48:35 EDT — (In reply to Alexey Tikhonov from comment #26) > I don't want to change message type for this message only: there are a lot > of similar places where we use `PAM_TEXT_INFO`. If `PAM_ERROR_MESSAGE` is a > proper type, we need to change it everywhere to be consistent. Yea I agree changing all error messages to be of type error is a good idea. It's a bit like making sure programs use fprintf(stderr, ...) instead of printf() when sending out errors to the console (as an analogy). You could image the frontend might display the messages different, emboldened, or with an exclamation icon or something (I don't think the graphical login screen currently does, mind you, but it has in the past, and could very well in the future). and of course it would fix the message preemption problem. > Managing display time via text len feels weird (and won't work with every > language, as pointed out). Agreed, that it's suboptimal. It's the current design though. There was a time in the past where we showed all the messages in a scrolling list. That was an awful experience. There's impedance mismatch here. The pam module is trying to service multiple front ends, some simpler than others, and so the generic-ness of it all and the inflexibility of the abstraction are sort of getting in the way. I guess if we really wanted to do a good job, fundamentally we would figure out what the user should see from end to end in this particular "smartcard blocked" scenario, and then figure out how to get their implementation wise. Maybe we'd use the normal PAM primitives, or come up with something more bespoke using a smartcard gdm pam extension + custom shell code, or something else. But if we're going to do that we should interface with Allan Day so we have proper designs etc (e.g. more work toward https://gitlab.gnome.org/Teams/Design/os-mockups/-/blob/master/lock-login/lock-screen.png) > - strings are already translated and pre-verified for 9.1, and I wouldn't > like to re-start the process Okay. That's unfortunate. > - "PIN locked" is really a very "classic" message I mean, it's a pretty direct translation of CKF_USER_PIN_LOCKED to prose, I guess, but when coming up with messages for the user, it's not always great to have a 1-to-1 close correspondence with low-level error codes. imo anyway. Anyway your call obviously. Note, I suggested we should fix both pam_sss and gnome-shell in comment 25. But the fixes are independent, so we can do one side without doing the other and get some benefit. (In reply to Scott Poore from comment #27) > Ray, would that be possible? Could we clone this bug to gnome-shell and use > that to investigate how complicated it will be to handle smartcards as a > special case for messages? I could try to run through some testing on my > side for that if needed too. Maybe planned for 9.2? Yea, I think we're on the same page. I'll hit clone button after I post this comment I guess.

Release Notes

No. of Comments

Resolution

Unresolved