Description of problem:
gnome-screensaver will attempt to authenticate even if the user hits cancel. For clients using login restrictions this causes problems such as account lockout
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Lock with gnome-screensaver
2. Move mouse to bring up unlock dialog
3. hit cancel
rinse & repeat
gnome-screensaver-dialog: pam_unix(gnome-screensaver:auth): auth could not identify password for [tom]
Authentication should not happen if user hits cancel
Gnome bug that is related
Created attachment 433096 [details]
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.
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.