Fedora DS 1.0.1 on RHEL4 Using the ldappasswd command to change a user's password crashes the server. I tried to reproduce on Fedora Core 4, but I could not reproduce the crash. You have to first enable SSL on the server (see the Howto:SSL on the wiki) because you cannot use ldappasswd without SSL. Then, as a user (I used a user from the Example.ldif), attempt to change your own password.
Need to reproduce on RHEL4 and the original reporter is going to attach some config files and logs to this bug.
Created attachment 124052 [details] nss_ldap config file at use when I experienced the bug /etc/ldap.conf
Created attachment 124053 [details] openldap-clients config file /etc/openldap/ldap.conf file being used
Created attachment 124054 [details] slapd-access log /opt/fedora-ds/slapd-ldapserver/slapd-access file
Created attachment 124055 [details] errors log /opt/fedora-ds/slapd-ldapserver/slapd-errors
I have FDS 1.0.1 running on CentOs 4.2
It looks as though none of the attempts to change the password were successful, despite what ldappasswd may have said. If you look at the attached access log, and search for passwd_modify_extop, you will see that all of the attempts failed with one of the following result codes: err=13 - CONFIDENTIALITY_REQUIRED - an attempt to use the password_modify_extop was made on an insecure connection err=89 - INVALID_PARAM - either the old or the new password was not given err=19 - CONSTRAINT_VIOLATION - the new password did not conform to the syntax (i.e. not long enough), or was already in the password history, or the user is not allowed to change it yet, or the user exceeded the password retry limit. I'm trying to see if any of the error conditions cause a failure. So far, neither err=13 nor err=89 seems to cause any problems. I'm going to turn on password syntax checking to see if that breaks anything.
I've tried and tried repeatedly to get this to fail, but so far, no crash. I'm using Fedora Core 4. I even ran the code under valgrind 2.4 - I found some memory leaks in the password extop code, but no other problems that would cause a crash. What is your exact ldappasswd command? I'm using something like: ldappasswd -ZZ -x -h localhost -p 10000 -a "98765432109876543210" -s "01234567890123456789" -D "uid=scarter,ou=people,dc=example,dc=com" -w 98765432109876543210 "uid=scarter,ou=people,dc=example,dc=com" I've tried it without the DN on the end (defaults to the BIND DN), with and without the -ZZ, -s, and -a, and various combinations.
The command I used to execute, which now I see has an extra -ZZ in there #ldappasswd -ZZ -x -d 3 -h ldapserver.fqdn -D 'uid=jdtroy,ou=People,dc=example,dc=com' -w oldpwd -S -a oldpwd -ZZ 'uid=jdtroy,ou=People,dc=example,dc=com' I retried with the command you wrote down above, and I still have the same problem. I am using policies [password history (remember:5) - password expiration: max 90 days - warn: 14 days - lockout after 3 failures - check password syntax (min 6 characters + use MD5 hash algorithm)] Below the command I used now: # ldappasswd -ZZ -x -h ldapserver.fqdn -a odlpwd -s newpwd -D 'uid=jdtroy,ou=People,dc=example,dc=com' -w oldpwd 'uid=jdtroy,ou=People,dc=example,dc=com'
Using the latest code (CVS head - proposed FDS 1.0.2 candidate) I cannot reproduce. I tried both of the forms above. We have fixed some bugs in this area of the code, so perhaps those fixes solved this problem as well.
I am currently able to crash the server every time after a successful password modify extended operation, with 1.0.2 release. It didn't crash before I had enabled password expiration. After I disabled password expiration and tested again, it continues to crash.
*** passwd_extop.c.~1.7.~ 2006-02-15 14:16:53.000000000 -0700 --- passwd_extop.c 2006-03-06 10:47:51.000000000 -0700 *************** *** 135,141 **** static int passwd_apply_mods(const char *dn, Slapi_Mods *mods) { Slapi_PBlock pb; - Slapi_Operation *operation= NULL; int ret=0; LDAPDebug( LDAP_DEBUG_TRACE, "=> passwd_apply_mods\n", 0, 0, 0 ); --- 135,140 ---- *************** *** 150,158 **** pw_get_componentID(), /* PluginID */ 0); /* Flags */ - /* Plugin operations are INTERNAL by default, bypass it to enforce ACL checks */ - slapi_pblock_get (&pb, SLAPI_OPERATION, &operation); - ret =slapi_modify_internal_pb (&pb); slapi_pblock_get(&pb, SLAPI_PLUGIN_INTOP_RESULT, &ret); --- 149,154 ---- *** pw.c.~1.9.~ 2006-02-15 14:32:11.000000000 -0700 --- pw.c 2006-03-06 10:58:16.000000000 -0700 *************** *** 647,654 **** pw_apply_mods(dn, &smods); slapi_mods_done(&smods); ! /* reset c_needpw to 0 */ ! pb->pb_conn->c_needpw = 0; return 0; } --- 647,656 ---- pw_apply_mods(dn, &smods); slapi_mods_done(&smods); ! if (pb->pb_conn) { /* no conn for internal op */ ! /* reset c_needpw to 0 */ ! pb->pb_conn->c_needpw = 0; ! } return 0; }
Reviewed by: Pete, Nathan (Thanks!) Files: passwd_extop.c pw.c Branch: HEAD Fix Description: The passwd_extop code does an internal operation to change the password. Some of this code is only intended to be called for external operations where you have a conn structure. The one place in particular which caused this bug is in update_pw_info, where it is only triggered if you must change the password or password expiration is in effect. The fix is to just check to see if the pb_conn is not null. Platforms tested: Fedora Core 4 Flag Day: no Doc impact: no /cvs/dirsec/ldapserver/ldap/servers/slapd/pw.c,v <-- pw.c new revision: 1.10; previous revision: 1.9 done Checking in passwd_extop.c; /cvs/dirsec/ldapserver/ldap/servers/slapd/passwd_extop.c,v <-- passwd_extop.c new revision: 1.8; previous revision: 1.7 done
Verified. See attached.
Oops. I am addressing the wrong bug #. Changed status back to MODIFIED
ignore comment #16 above.