Bug 553455 - ns-slapd segfaults when trying to change password
ns-slapd segfaults when trying to change password
Product: 389
Classification: Community
Component: Security - Password Policy (Show other bugs)
All Linux
high Severity high
: ---
: ---
Assigned To: Nathan Kinder
Viktor Ashirov
Depends On:
Blocks: 434914 389_1.2.5
  Show dependency treegraph
Reported: 2010-01-07 17:27 EST by Chris St. Pierre
Modified: 2015-12-07 11:33 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-12-07 11:33:17 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:

Attachments (Terms of Use)
Proposed Patch (1.37 KB, patch)
2010-01-08 19:10 EST, Nathan Kinder
rmeggins: review+
Details | Diff

  None (edit)
Description Chris St. Pierre 2010-01-07 17:27:29 EST
Description of problem:

I have set the following per-user password history:

% ldapsearch -h groucho -xLLL -D "cn=directory manager" -W -b "cn=config" \
  -s base "cn=config" nsslapd-pwpolicy-local
dn: cn=config
nsslapd-pwpolicy-local: on

% ldapsearch -xLLL -D "cn=directory manager" -W -b \
  "cn=nsPwPolicyContainer,ou=people,o=nebrwesleyan.edu,o=isp" \
  'objectClass=ldapSubEntry' passwordHistory passwordInHistory
dn: cn="cn=nsPwPolicyEntry,uid=ppolicy,ou=people,o=nebrwesleyan.edu,o=isp",cn=
passwordHistory: on
passwordInHistory: 10

I created the initial entries and containers using ns-newpwpolicy.pl.

Now, when I try to change that user's password using ldappasswd, ns-slapd segfaults:

% sudo service dirsrv status
dirsrv groucho (pid 17450) is running...

% ldappasswd -h groucho -xZZ -D 'uid=ppolicy,ou=people,o=nebrwesleyan.edu,o=isp' -W -S
New password:
Re-enter new password:
Enter LDAP Password:
ldappasswd: ldap_result: Can't contact LDAP server (-1)

% sudo service dirsrv status
dirsrv groucho dead but pid file exists

In the 389 error logs, I only get:

[07/Jan/2010:15:28:15 -0600] - Missing userIdentity in request, using the bind DN instead.

dmesg shows the segfault:

ns-slapd[19337]: segfault at 0000000000000018 rip 00002b03b873bd5f rsp 000000004eda8880 error 4

The segfault happens every time I try to change this user's password using ldappasswd.  If I use ldappasswd to change the password of a user who does not have a password policy, it works fine and ns-slapd does not segfault.

Version-Release number of selected component (if applicable):

% rpm -q 389-ds-base

The problem also occurs with RC2.
Comment 1 Chris St. Pierre 2010-01-07 17:28:15 EST
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 "")
    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
Comment 2 Nathan Kinder 2010-01-07 18:41:52 EST
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.
Comment 3 Nathan Kinder 2010-01-08 11:32:28 EST
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.
Comment 4 Chris St. Pierre 2010-01-08 11:55:14 EST
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!
Comment 5 Nathan Kinder 2010-01-08 13:34:20 EST
(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.
Comment 6 Rich Megginson 2010-01-08 13:43:31 EST
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.
Comment 7 Nathan Kinder 2010-01-08 19:10:35 EST
Created attachment 382579 [details]
Proposed Patch
Comment 8 Rich Megginson 2010-01-08 20:47:22 EST
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.
Comment 9 Nathan Kinder 2010-01-11 11:55:44 EST
(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.
Comment 10 Nathan Kinder 2010-01-11 12:26:53 EST
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
Comment 13 Jenny Galipeau 2010-05-21 09:48:06 EDT
verified - RHEL 4


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=
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

Note You need to log in before you can comment on or make changes to this bug.