Description of problem: because of openssh's design, it calls pam_open_session before forking in do_exec_*pty. Then, if the user's password has expired, it calls pam_chauthtok after forking and setting up the tty. This is contrary to standard (and I presume also recommended) PAM usage, and in the case of pam_ldap it causes a series of SEGVs which prevent the password change from occurring and terminate the connection. Version-Release number of selected component (if applicable): openssh-3.6.1p2-33.30.1 How reproducible: Always if using LDAP authentication with password aging objects. Steps to Reproduce: 1. Expire an LDAP user's password (I did it using ldapmodify) 2. Attempt to initiate an ssh login session as the LDAP user 3. Actual results: [dlehman@gonzo xchatlogs]$ ssh ldapuser@hogwash ldapuser@hogwash's password: You are required to change your LDAP password immediately. Warning: Your password has expired, please change it now. Connection to hogwash closed. [dlehman@gonzo xchatlogs]$ Expected results: [dlehman@gonzo nss_ldap-226]$ ssh ldapuser@hogwash ldapuser@hogwash's password: You are required to change your password immediately (password aged) You are required to change your LDAP password immediately. Warning: Your password has expired, please change it now. Enter login(LDAP) password: New password: Retype new password: LDAP password information changed for ldapuser Last login: Wed Oct 20 13:46:48 2004 from gonzo.hsv.redhat.com (and so on...) Additional info: This is directly related to the hack in pam_sm_open_session in pam_ldap.c (nss_ldap) that manually calls the session cleanup function when a session is opened. Commenting that bit out makes the problem go away.
> This is directly related to the hack in pam_sm_open_session in > pam_ldap.c (nss_ldap) that manually calls the session cleanup function > when a session is opened. Commenting that bit out makes the problem go away. This is a real bug because the cleanup is not done right - it should be done this way: pam_set_data (pamh, PADL_LDAP_SESSION_DATA, NULL, NULL); So the data are correctly cleaned up and the data item is removed from libpam. After this is fixed it will be possible to retest if the bug still happens and if so I'll try to find some way how to reorder the calls.
Does this bug actually still happen after update of nss_ldap to version 207-15 in RHEL3 U5? This update should have resolved the most probable culprit of the crashing.
This bug is filed against RHEL 3, which is in maintenance phase. During the maintenance phase, only security errata and select mission critical bug fixes will be released for enterprise products. Since this bug does not meet that criteria, it is now being closed. For more information of the RHEL errata support policy, please visit: http://www.redhat.com/security/updates/errata/ If you feel this bug is indeed mission critical, please contact your support representative. You may be asked to provide detailed information on how this bug is affecting you.