Bug 553455
| Summary: | ns-slapd segfaults when trying to change password | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Retired] 389 | Reporter: | Chris St. Pierre <cstpierr> | ||||
| Component: | Security - Password Policy | Assignee: | Nathan Kinder <nkinder> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Viktor Ashirov <vashirov> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | high | ||||||
| Version: | 1.2.1 | CC: | jgalipea, nkinder | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2015-12-07 16:33:17 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 434914, 533025 | ||||||
| Attachments: |
|
||||||
|
Description
Chris St. Pierre
2010-01-07 22:27:29 UTC
The crash, reproduced under gdb:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x6139c940 (LWP 21075)]
pw_encodevals_ext (pb=0x6139baf0, sdn=<value optimized out>, vals=0x181b1f50) at ldap/servers/slapd/pw.c:354
354 pws_enc = pwpolicy->pw_storagescheme->pws_enc;
(gdb) bt
#0 pw_encodevals_ext (pb=0x6139baf0, sdn=<value optimized out>, vals=0x181b1f50) at ldap/servers/slapd/pw.c:354
#1 0x00002b8faf677336 in op_shared_modify (pb=0x6139baf0, pw_change=1,
old_pw=0x173fa480 "{SSHA}fW1o8ujutT2kxwYOBCMlVWhnDebD/WaMQTof0A==") at ldap/servers/slapd/modify.c:721
#2 0x00002b8faf677855 in modify_internal_pb (pb=0x6139baf0) at ldap/servers/slapd/modify.c:526
#3 0x000000000041e038 in passwd_modify_extop (pb=0x2aaaac2076e0) at ldap/servers/slapd/passwd_extop.c:181
#4 0x00002b8faf683e37 in plugin_call_exop_plugins (pb=0x2aaaac2076e0, oid=0x16ca0470 "1.3.6.1.4.1.4203.1.11.1")
at ldap/servers/slapd/plugin.c:441
#5 0x0000000000417585 in do_extended (pb=0x2aaaac2076e0) at ldap/servers/slapd/extendop.c:349
#6 0x0000000000412e3d in connection_threadmain () at ldap/servers/slapd/connection.c:617
#7 0x00002b8fb13a8fad in ?? () from /usr/lib64/libnspr4.so
#8 0x00002b8fb1d36617 in start_thread () from /lib64/libpthread.so.0
#9 0x00002b8fb1aacc2d in clone () from /lib64/libc.so.6
I think that the problem is due to the fact that the local policy does not have a storage scheme set, but I'll need to reproduce the issue to verify the cause. This issue does appear to be caused by the lack of a "passwordStorageScheme" attribute in the local policy entry. I have a fix that will prevent the crash, but you most likely do want to add a storage scheme setting to your local policy. A local policy is used exactly as specified in it's entirety, not in combination with the global policy. What this means is that having no storage scheme specified in the local policy will cause the password to not be hashed for the entries that the local policy applies to. The omission of the storage scheme will not cause the server to fall back to the global storage scheme for the local policy. This behavior is the same for all of the password policy attributes, not just the storage scheme. Adding 'passwordStorageScheme: SSHA' did indeed fix the problem. It seems, intuitively, like either the global storage scheme or the default storage scheme should apply to the local policy. If not, then ns-newpwpolicy.pl should probably create a default passwordStorageScheme attribute. Thanks for your help! (In reply to comment #4) > It seems, intuitively, like either the global storage scheme or the default > storage scheme should apply to the local policy. If not, then > ns-newpwpolicy.pl should probably create a default passwordStorageScheme > attribute. I tend to agree, though I am concerned about changing the behavior. We could make the storage scheme of the local policy inherit from the global policy if it is not set locally, but this would have the effect of changing the result of user's existing policies after an upgrade. It is probably unlikely that someone is depending on the current behaviour to enforce clear passwords without explicitly specifying the storage scheme, but we have no way of knowing for sure. The ns-newpwpolicy.pl script could also be easily modified to add a default storage scheme, but we don't add any other policy values. Perhaps the proper thing is to make the default storage scheme for a local policy SSHA when the "passwordStorageScheme" value is not set. This is in line with the way the global policy works. This has been a problem from day one - everyone intuitively expects the local password policy to inherit from the global password policy for fields that are not specified at the local level. I seriously doubt someone is relying on the existing behavior, fully understanding how it is supposed to work. But that is a separate issue - an enhancement request. I think it could be made to work by changing new_passwdPolicy to simply copy the settings from the global policy when creating the local policy object. Created attachment 382579 [details]
Proposed Patch
Comment on attachment 382579 [details]
Proposed Patch
Ok, but if the user doesn't set the local password policy, the passwords will mysteriously not be hashed, which is bad.
(In reply to comment #8) > (From update of attachment 382579 [details]) > Ok, but if the user doesn't set the local password policy, the passwords will > mysteriously not be hashed, which is bad. I filed bug 554419 as an RFE for inheriting the global policy settings when creating a local policy. Pushed fix from comment #7 to master. Thanks for the review! Counting objects: 11, done. Delta compression using 2 threads. Compressing objects: 100% (6/6), done. Writing objects: 100% (6/6), 737 bytes, done. Total 6 (delta 4), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git a7ac03c..786c740 master -> master verified - RHEL 4 version: redhat-ds-base-8.2.0-2010052104.el4dsrv 1. enabled global policy 2. ldapsearch -xLLL -h jgalipea-rhel4.idm.lab.bos.redhat.com -p 389 -D "cn=Directory Manager" -w Secret123 -b "cn=config" | grep nsslapd-pwpolicy-local nsslapd-pwpolicy-local: on 3. perl template-ns-newpwpolicy.pl -D "cn=Directory Manager" -w Secret123 -p 389 -h jgalipea-rhel4.idm.lab.bos.redhat.com -U "uid=jgalipea,ou=people,dc=example,dc=com" adding new entry cn=nsPwPolicyContainer,ou=people,dc=example,dc=com adding new entry cn=cn=nsPwPolicyEntry\,uid=jgalipea\,ou=people\,dc=example\,dc=com,cn=nsPwPolicyContainer,ou=people,dc=example,dc=com modifying entry uid=jgalipea,ou=people,dc=example,dc=com modifying entry cn=config 4. no passwordStorageSchema [root@jgalipea-rhel4 slapd-jgalipea-rhel4]# ldapsearch -xLLL -h jgalipea-rhel4.idm.lab.bos.redhat.com -p 389 -D "cn=Directory Manager" -w Secret123 -b "ou=people,dc=example,dc=com" 'objectClass=ldapSubEntry' dn: cn=cn=nsPwPolicyEntry\2Cuid=jgalipea\2Cou=people\2Cdc=example\2Cdc=com,cn= nsPwPolicyContainer,ou=people,dc=example,dc=com objectClass: top objectClass: ldapsubentry objectClass: passwordpolicy cn: cn=nsPwPolicyEntry,uid=jgalipea,ou=people,dc=example,dc=com 5. [root@jgalipea-rhel4 slapd-jgalipea-rhel4]# /usr/lib/mozldap6/ldappasswd -v -ZZ -h jgalipea-rhel4.idm.lab.bos.redhat.com -p 389 -D "uid=jgalipea,ou=people,dc=example,dc=com" -w ':tDbv75B' -S New Password: Re-enter new Password: ldappasswd: started Fri May 21 09:43:17 2010 ldap_init( jgalipea-rhel4.idm.lab.bos.redhat.com, 389 ) ldaptool_getcertpath -- . ldaptool_getkeypath -- . ldaptool_getmodpath -- (null) ldaptool_getdonglefilename -- (null) ldappasswd: password successfully changed |