After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 387572 - auth hangs when password is expired
auth hangs when password is expired
Status: RESOLVED FIXED
Product: gnome-screensaver
Classification: Deprecated
Component: daemon
CVS HEAD
Other Linux
: Normal critical
: ---
Assigned To: gnome-screensaver maintainers
gnome-screensaver maintainers
: 388642 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-12-19 17:07 UTC by William Jon McCann
Modified: 2006-12-23 13:48 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
patch (6.04 KB, patch)
2006-12-20 20:58 UTC, William Jon McCann 		committed Details | Review

Description William Jon McCann 2006-12-19 17:07:08 UTC 
To reproduce on 2.17:

1. sudo chage -d 0 USERNAME
2. Run ./src/test-passwd
3. Enter password
4. Hangs

Might be due to the changes in bug #373556
Comment 1 William Jon McCann 2006-12-20 20:37:02 UTC 
I've added some more verbosity in HEAD.

./test-passwd 
** Message: pam_start ("gnome-screensaver", "mccannwj", ...) ==> 0 (Success)
** Message: Handling message style 1: 'Password: '
** Message: Waiting for lock
** Message: Waiting for respose to message style 1: 'Password: '
** Message: Waiting for response
** Message: Got message style 1: 'Password: '
Password: ** Message: Got response
** Message: Got respose to message style 1: interrupt:0
** Message: Msg handler returned 1

** Message:    pam_authenticate (...) ==> 0 (Success)
** Message: Handling message style 2: 'You are required to change your password immediately (root enforced)'
** Message: Waiting for respose to message style 2: 'You are required to change your password immediately (root enforced)'


And here's the gdb bt:
(gdb) thread apply all bt

+ Trace 95766

Thread 1 (Thread -1208658240 (LWP 24987))

  • #0 __kernel_vsyscall
  • #1 pthread_cond_wait
    from /lib/libpthread.so.0
  • #2 pam_conversation
    at gs-auth-pam.c line 239
  • #3 pam_vprompt
    from /lib/libpam.so.0
  • #4 pam_prompt
    from /lib/libpam.so.0
  • #5 pam_sm_open_session
    from /lib/security/pam_unix.so
  • #6 pam_sm_acct_mgmt
    from /lib/security/pam_unix.so
  • #7 _pam_dispatch
    from /lib/libpam.so.0
  • #8 pam_acct_mgmt
    from /lib/libpam.so.0
  • #9 gs_auth_verify_user
    at gs-auth-pam.c line 657
  • #10 main
    at test-passwd.c line 250 






Comment 2


William Jon McCann





          2006-12-20 20:58:47 UTC
        



Created attachment 78711 [details] [review]
patch

I think the problem is waiting on the GCond in the message handler that is called from the pam_conv assumes that it is not running in the same thread as the gui.  So, I think just moving all the pam stuff into the thread solves the problem.

Ray, what do you think?






Comment 3


Ray Strode [halfline]





          2006-12-21 06:15:42 UTC
        



Yea, it sounds like you hit the nail on the head.

It might be worthwhile to add an assert at the top of gs_auth_run_message_handler that checks that g_thread_equal (g_thread_self, gui_thread) fails.

is gs_auth_identify_user still a good name now that it includes the account management bits?






Comment 4


William Jon McCann





          2006-12-21 17:51:37 UTC
        



Ok so I committed this with the function renamed.

That is a good idea about the assert.  I'd like to add that when I get a bit more time.  Wasn't aware of g_thread_equal...






Comment 5


William Jon McCann





          2006-12-23 13:48:52 UTC
        



*** Bug 388642 has been marked as a duplicate of this bug. ***