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: | gdm | Assignee: | Ray Strode [halfline] <rstrode> | ||||||||
Status: | CLOSED ERRATA | QA Contact: | Desktop QE <desktop-qa-list> | ||||||||
Severity: | unspecified | Docs Contact: | |||||||||
Priority: | unspecified | ||||||||||
Version: | 6.4 | CC: | 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: | |||||||||
Embargoed: | |||||||||||
Attachments: |
|
Description
Chad Hanson
2013-06-24 22:51:24 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.
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.
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.
Patch applied to gdm-2.30.4-52.el6 marking MODIFIED for QE. 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 |