Full_Name: Michael Str.der Version: 2.4.48 / RE24 branch OS: openSUSE Linux URL: Submission from: (NULL) (213.240.182.73) slapd seg faults in case the client sends a modify operation like this (let me know if you need a stack trace): ----------------------------- snip ----------------------------- $ ldapmodify -e relax << EOF dn: uid=test42,ou=Testing,dc=stroeder,dc=de changetype: modify add: pwdChangedTime pwdChangedTime: 19721101000000Z EOF SASL/EXTERNAL authentication started SASL username: gidNumber=100+uidNumber=1000,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "uid=test42,ou=Testing,dc=stroeder,dc=de" ldap_result: Can't contact LDAP server (-1) ----------------------------- snip ----------------------------- Note that this only happens in case the userPassword was *freshly* set via Password Modify ext. op. If the client sends a modify operation with 'replace: pwdChangedTime' this works correctly and after that 'add: pwdChangedTime' is correctly rejected: ----------------------------- snip ----------------------------- $ ldapmodify -e relax << EOF dn: uid=test42,ou=Testing,dc=stroeder,dc=de changetype: modify replace: pwdChangedTime pwdChangedTime: 19721101000000Z EOF SASL/EXTERNAL authentication started SASL username: gidNumber=100+uidNumber=1000,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "uid=test42,ou=Testing,dc=stroeder,dc=de" $ ldapmodify -e relax << EOF dn: uid=test42,ou=Testing,dc=stroeder,dc=de changetype: modify add: pwdChangedTime pwdChangedTime: 19721101000000Z EOF SASL/EXTERNAL authentication started SASL username: gidNumber=100+uidNumber=1000,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "uid=test42,ou=Testing,dc=stroeder,dc=de" ldap_modify: Type or value exists (20) additional info: modify/add: pwdChangedTime: value #0 already exists ----------------------------- snip -----------------------------
This still happens with current RE24 snapshot. Is more information needed to address this?
On Mon, Jan 13, 2020 at 09:35:18PM +0000, michael@stroeder.com wrote: > This still happens with current RE24 snapshot. > > Is more information needed to address this? Hi, had a look at it and a proposed patch is in a branch in my GitHub repo: https://github.com/mistotebe/openldap/tree/its9126 Let me know if this fixes the issue for you. As far as I have been able to figure out, the database content generated by ppolicy until now was inconsistent with the schema (normalised value was missing) and existing values will still cause the crash to happen. A fix is to replace the affected values or export/reload the database. Thanks, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
changed notes changed state Open to Release moved from Incoming to Software Bugs
Fixed in master Fixed in RE24 (2.4.49)
changed notes changed state Release to Closed