Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 918684

Summary: modify-delete userpassword
Product: Red Hat Enterprise Linux 7 Reporter: Nathan Kinder <nkinder>
Component: 389-ds-baseAssignee: Rich Megginson <rmeggins>
Status: CLOSED CURRENTRELEASE QA Contact: Sankar Ramalingam <sramling>
Severity: unspecified Docs Contact:
Priority: medium    
Version: 7.0CC: amsharma, jgalipea, mreynolds, nhosoi, vashirov
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: 389-ds-base-1.3.1.2-1.el7 Doc Type: Bug Fix
Doc Text:
Cause: Deleting a specific userpassword, the clear text password was being compared the encoded password. Consequence: Internally the provided clear text password was being compared to the stored encoded password value. An error 16 is returned because it can not find a match. Fix: During the delete, we check if the value to delete is encoded. If it is not, then it gets encoded so it can be compared to the existing encoded values in the entry. Result: The delete of a specific userpassword is successful.
 Story Points: ---
Clone Of:
: 1053232 (view as bug list) Environment:
Last Closed: 2014-06-13 10:19:22 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: 1053232    

Description Nathan Kinder 2013-03-06 18:12:38 UTC 
This bug is created as a clone of upstream ticket:
https://fedorahosted.org/389/ticket/394

Steps to duplicate this issue:
1. A user uid=tuser0,ou=People,dc=example,dc=com has a userpassword: newpassword.
2. delete the userpassword with the value.
    ldapmodify ...
    dn: uid=tuser0,ou=People,dc=example,dc=com
    changetype: modify
    delete: userpassword
    userpassword: newpassword

    ldap_modify: No such attribute

Internally, the newpassword in the mod has the value:

    (gdb) p *vals[0]
    $19 = {bv_len = 46,
      bv_val = 0x7f6b940055f0 "{SSHA}Uj1d+WvfAfa/hx2eCnM3WuJJzxEtprB37SbArA=="}

while the value in the entry is hashed differently.

    (gdb) p *a->a_present_values.va[0]
    $23 = {bv = {bv_len = 46,
        bv_val = 0x7f6b940056a0 "{SSHA}s9Jcj0zOofoEK4HgyUugR/KVOE8hOaJhftTNvw=="},
      v_csnset = 0x7f6b9400acc0, v_flags = 0}

The failed point:

    (gdb) bt
    #0  entry_delete_present_values_wsi (e=0x7f6b94000a30,
        type=0x7f6b94007f10 "userPassword", vals=0x7f6b94007e40,
        csn=0x7f6bb9ff4960, urp=0, mod_op=129, replacevals=0x0)
        at ldap/servers/slapd/entrywsi.c:597
    #1  0x00007f6bc9d8cb8a in entry_apply_mod_wsi (e=0x7f6b94000a30,
        mod=0x7f6b94007f30, csn=0x7f6bb9ff4960, urp=0)
        at ldap/servers/slapd/entrywsi.c:733
    #2  0x00007f6bc9d8cd73 in entry_apply_mods_wsi (e=0x7f6b94000a30,
        smods=0x7f6bb9ff4a10, csn=0x7f6b9400c8c0, urp=0)
        at ldap/servers/slapd/entrywsi.c:776
    #3  0x00007f6bc528bf05 in ldbm_back_modify (pb=0x2488680)
        at ldap/servers/slapd/back-ldbm/ldbm_modify.c:321
    #4  0x00007f6bc9db7acc in op_shared_modify (pb=0x2488680, pw_change=1,
        old_pw=0x0) at ldap/servers/slapd/modify.c:936
    #5  0x00007f6bc9db6851 in do_modify (pb=0x2488680)
        at ldap/servers/slapd/modify.c:405
    #6  0x0000000000413ff7 in connection_dispatch_operation (conn=0x7f6bc02cfbf0,
        op=0x24d7c70, pb=0x2488680) at ldap/servers/slapd/connection.c:591
    #7  0x00000000004159de in connection_threadmain ()
        at ldap/servers/slapd/connection.c:2336
    #8  0x0000003d20628793 in _pt_root (arg=0x24cfd00)
        at ../../../mozilla/nsprpub/pr/src/pthreads/ptthread.c:187
    #9  0x0000003d16e07d90 in start_thread (arg=0x7f6bb9ffb700)
        at pthread_create.c:309
    #10 0x0000003d16af0f5d in clone ()
        at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115

Next, I tried the returned value from search, then the userPassword value matches the one in the entry.

    userpassword: {SSHA}s9Jcj0zOofoEK4HgyUugR/KVOE8hOaJhftTNvw==

But, now it fails to delete unhashed#user#password in the entry since it stores the clear text.

We can specially delete the unhashed password without checking the value.  But if an entry has multiple userPasswords, it may cause a problem if we cannot delete just one of them...  Even if we stash the clear text passwords in the extension (as I'm working on it now), we still have the same problem.  Probably, the right thing to do would be letting modify-delete take a clear text password and we should match the passwords considering the hash?

     527 static int
     528 entry_delete_present_values_wsi(Slapi_Entry *e, const char *type, struct berval **vals, const CSN *csn, int urp, int mod_op, struct berval **replacevals)
            [...]
     596                 retVal= valueset_remove_valuearray(&a->a_present_values, a, valuestodelete, 0 /* Do Not I gnore Errors */,&deletedvalues);
           <== this returns error LDAP_NO_SUCH_ATTRIBUTE (16)
Comment 1 Rich Megginson 2013-10-01 23:24:09 UTC 
moving all ON_QA bugs to MODIFIED in order to add them to the errata (can't add bugs in the ON_QA state to an errata).  When the errata is created, the bugs should be automatically moved back to ON_QA.
Comment 3 Amita Sharma 2013-12-20 07:24:11 UTC 
[root@cloud-qe-1-vm-2 ~]# cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 6.5 (Santiago)

[root@cloud-qe-1-vm-2 ~]# rpm -qf `which ns-slapd`
389-ds-base-1.2.11.25-1.el6.i686

ldapadd -x -h localhost -p 389 -D "cn=Directory Manager" -w Secret123  << EOF
dn: uid=ams,ou=People,dc=example,dc=com
cn: ams
sn: ams
givenname: ams
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
uid: ams
mail: ams
userpassword: newpassword
EOF

[root@cloud-qe-1-vm-2 ~]# ldapmodify -x -h localhost -p 389 -D "cn=Directory Manager" -w Secret123  << EOF
dn: uid=ams,ou=People,dc=example,dc=com
changetype: modify
delete: userpassword
userpassword: newpassword
EOF
modifying entry "uid=ams,ou=People,dc=example,dc=com"
ldap_modify: No such attribute (16)


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
[root@dhcp201-149 ldapbertest]# cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 7.0 Beta (Maipo)

[root@dhcp201-149 ldapbertest]# rpm -qf `which ns-slapd`
389-ds-base-1.3.1.6-12.el7.x86_64

[root@dhcp201-149 ldapbertest]# ldapadd -x -h localhost -p 389 -D "cn=Directory Manager" -w Secret123  << EOF
> dn: uid=ams,ou=People,dc=example,dc=com
> cn: ams
> sn: ams
> givenname: ams
> objectclass: top
> objectclass: person
> objectclass: organizationalPerson
> objectclass: inetOrgPerson
> uid: ams
> mail: ams
> userpassword: newpassword
> EOF
adding new entry "uid=ams,ou=People,dc=example,dc=com"

[root@dhcp201-149 ldapbertest]# ldapmodify -x -h localhost -p 389 -D "cn=Directory Manager" -w Secret123  << EOF
> dn: uid=ams,ou=People,dc=example,dc=com
> changetype: modify
> delete: userpassword
> userpassword: newpassword
> EOF
modifying entry "uid=ams,ou=People,dc=example,dc=com"

[root@dhcp201-149 ldapbertest]# ldapsearch -x -h localhost -p 389 -D "cn=Directory Manager" -w Secret123 -b "ou=People,dc=example,dc=com"
# ams, People, example.com
dn: uid=ams,ou=People,dc=example,dc=com
cn: ams
sn: ams
givenName: ams
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
uid: ams
mail: ams
Comment 5 Ludek Smid 2014-06-13 10:19:22 UTC 
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.