Bug 977560

Summary: smartcard authentication is unavailable with disable_user_list if first attempt fails
Product: Red Hat Enterprise Linux 6 Reporter: Chad Hanson <chanson>
Component: gdmAssignee: Ray Strode [halfline] <rstrode>
Status: CLOSED ERRATA QA Contact: Desktop QE <desktop-qa-list>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.4CC: jkoten, mdomonko, tlavigne, tpelka
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: gdm-2.30.4-52.el6 Doc Type: Bug Fix
Doc Text:
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
 Story Points: ---
Clone Of: Environment:
Last Closed: 2013-11-21 23:33:49 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
Patch to remove dialog reset
none
Patch to reset next_mode after queue has been cleared
none
Patch to initialize next_mode in reset_dialog none

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