Bug 606845
Summary: | attempts to authenticate on cancel or dialog timeout | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 5 | Reporter: | Jeremy West <gss-xmlrpc> | ||||||
Component: | gnome-screensaver | Assignee: | Ray Strode [halfline] <rstrode> | ||||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Desktop QE <desktop-qa-list> | ||||||
Severity: | high | Docs Contact: | |||||||
Priority: | urgent | ||||||||
Version: | 5.7 | CC: | cmeadors, cward, jwest, ofourdan, pvine, rstrode, tpelka, vbenes | ||||||
Target Milestone: | rc | Keywords: | ZStream | ||||||
Target Release: | --- | ||||||||
Hardware: | All | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | 2.16.1-9.el5 | Doc Type: | Bug Fix | ||||||
Doc Text: |
When unlocking the screen, clicking the "Cancel" button may have caused the following message to appear in the /var/log/secure log:
gnome-screensaver-dialog: pam_unix(gnome-screensaver:auth): auth could not identify password for [user]
This was due to authentication dialog attempting to log in, even though no such action was requested. With this update, this error has been fixed, and clicking "Cancel" no longer attempts to authenticate a user.
|
Story Points: | --- | ||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2012-05-03 16:55:17 UTC | Type: | --- | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Bug Depends On: | |||||||||
Bug Blocks: | 644823, 807971 | ||||||||
Attachments: |
|
Description
Jeremy West
2010-06-22 15:38:56 UTC
Gnome bug that is related https://bugzilla.gnome.org/show_bug.cgi?id=373556 and revision http://svn.gnome.org/viewvc/gnome-screensaver/trunk/src/gs-auth-pam.c?annotate=1023 Created attachment 433096 [details]
Proposed patch
I believe the issue is a race conditon when the gnome-screensaver-dialog terminates without a password being provided.
The issue is fairly random, but further testing show that gnome-screensaver-2.16 as well as gnome-screensaver-2.18 have that problem while gnome-screensaver-2.20 does not.
A bit of bisection gave the following patch, which has been tested locally (by checking for an authentication error in /var/log/secure when cancel is pressed in the dialog).
A test package containing this patch has been passed to our customer who confirmed that the patch works in their environment as well.
Jon and I have been looking into this bug recently.
It doesn't appear that attachment 433096 [details] is right. We already send a SIGTERM (via the raise() syscall) when the user clicks cancel.
gnome-screensaver has two different threads. One thread is the main gui thread and the other thread is a helper thread for processing the blocking pam conversation.
The current thoery is that the raise(SIGTERM) is essentially randomly going to one of the threads. One time it may go to the main thread, another time it may go to the helper thread.
If it goes to the helper thread then everything will die right away leaving no failed entry in syslog.
If it goes to the main thread then the helper thread will get EINTR and that failure will cause the entry to be posted.
This is just a summary of the current findings, we're still actively looking for the "right" fix for this problem.
Created attachment 441059 [details]
proof of concept patch
Can you try this patch out and see if it solves your problem? Thanks.
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: When unlocking the screen, clicking the "Cancel" button may have caused the following message to appear in the /var/log/secure log: gnome-screensaver-dialog: pam_unix(gnome-screensaver:auth): auth could not identify password for [user] This was due to authentication dialog attempting to log in, even though no such action was requested. With this update, this error has been fixed, and clicking "Cancel" no longer attempts to authenticate a user. |