|Summary:||smartcard authentication is unavailable with disable_user_list if first attempt fails|
|Product:||Red Hat Enterprise Linux 6||Reporter:||Chad Hanson <chanson>|
|Component:||gdm||Assignee:||Ray Strode [halfline] <rstrode>|
|Status:||CLOSED ERRATA||QA Contact:||Desktop QE <desktop-qa-list>|
|Version:||6.4||CC:||jkoten, mdomonko, tlavigne, tpelka|
|Fixed In Version:||gdm-2.30.4-52.el6||Doc Type:||Bug Fix|
Cause: systems with smartcards configured, and user list disabled. Consequence: smartcard authentication is unaviable. Fix: Ensure smartcard authentication UI functions when user list disabled Result: smartcards work on login screens that have no user list
|Last Closed:||2013-11-21 23:33:49 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Chad Hanson 2013-06-24 22:51:24 UTC
Description of problem: When using smartcard authentication with disable_user_list=True a failed PIN attempt disables all further Smart Card logins until a successful login has occurred. Version-Release number of selected component (if applicable): gdm-2.30.4-39.el6 How reproducible: Every time Steps to Reproduce: 1. Enable Smart Card Authentication 2. Disable User List 3. Insert Sart Card and enter Incorrect PIN 4. Remove Smart Card and Reinsert Actual results: You should be prompted for your PIN Expected results: PIN prompt comes and then goes away very quickly. Additional info: This occurs due to on_conversation_messages_set() being called during MODE_AUTHENTICATION of the first PIN attempt. During the second attempt, this function is called again since next_mode is not MODE_UNDEFINED, reset_dialog_after_messages() is called which resets the login window. See Bug 719647 for the feature enhancement and more detail on the setup.
Comment 2 Chad Hanson 2013-06-24 22:57:14 UTC
Created attachment 764798 [details] Patch to remove dialog reset Here is a patch to remove the functionality that is causing the problem. I am not clear on the impact to [PATCH 36/38] queue instead of overwrite consecutive messages though in gdm-multistack.patch since it added this functionality.
Comment 3 Chad Hanson 2013-06-25 20:28:08 UTC
Created attachment 765279 [details] Patch to reset next_mode after queue has been cleared This updated patch resets next_mode to MODE_UNDEFINED after the message queue has been cleared. This way the next invocation of on_conversation_messages_set() after dialog has been reset will not result in resetting the dialog again since the next_mode is now MODE_UNDEFINED.
Comment 4 Chad Hanson 2013-06-25 23:04:50 UTC
Created attachment 765311 [details] Patch to initialize next_mode in reset_dialog I didn't get to test my previous patch before posting. That patch only worked some of the time. I would suspect there are still some direct calls to reset_dialog() so the initialization in reset_dialog_after_messages() isn't guaranteed to work. This patch should resolve that and hopefully is in the correct spot this time.
Comment 6 Ray Strode [halfline] 2013-09-26 15:23:33 UTC
Patch applied to gdm-2.30.4-52.el6 marking MODIFIED for QE.
Comment 10 errata-xmlrpc 2013-11-21 23:33:49 UTC
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. http://rhn.redhat.com/errata/RHBA-2013-1708.html