RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 977560 - smartcard authentication is unavailable with disable_user_list if first attempt fails
Summary: smartcard authentication is unavailable with disable_user_list if first attem...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: gdm
Version: 6.4
Hardware: Unspecified
OS: Linux
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Ray Strode [halfline]
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-06-24 22:51 UTC by Chad Hanson
Modified: 2014-01-02 10:28 UTC (History)
4 users (show)

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
Clone Of:
Environment:
Last Closed: 2013-11-21 23:33:49 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Patch to remove dialog reset (691 bytes, patch)
2013-06-24 22:57 UTC, Chad Hanson 		no flags Details | Diff
Patch to reset next_mode after queue has been cleared (555 bytes, patch)
2013-06-25 20:28 UTC, Chad Hanson 		no flags Details | Diff
Patch to initialize next_mode in reset_dialog (619 bytes, patch)
2013-06-25 23:04 UTC, Chad Hanson 		no flags Details | Diff
Show Obsolete (2) View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:1708 0 normal SHIPPED_LIVE gdm bug fix update 2013-11-21 00:39:27 UTC

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
Note You need to log in before you can comment on or make changes to this bug.