Issue 8184 - MOD operation with a double delete of a pwdFailureTime attribute
Summary: MOD operation with a double delete of a pwdFailureTime attribute
Status: VERIFIED FIXED
Alias: None
Product: OpenLDAP
Classification: Unclassified
Component: slapd (show other issues)
Version: 2.4.40
Hardware: All All
: --- normal
Target Milestone: ---
Assignee: OpenLDAP project
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-07-02 10:58 UTC by elecharny@openldap.org
Modified: 2015-08-18 17:41 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description elecharny@openldap.org 2015-07-02 10:58:56 UTC
Full_Name: Emmanuel L.charny
Version: 2.4.40
OS: 
URL: 
Submission from: (NULL) (212.195.127.200)


We get an error when trying to change a password in some combinaison of settings
:

- 2 servers, one being the master, one being the slave
- a few backends (MDB)
- one of those backends using the glue overlay, the other being subordinates
- 2 backends using the PPolicy overlay : the one which is the parent, and
another one being a subordinate. FTR, the PPolicy in use are different

What happens is that the password update will try to delete the pwdFailureTime
attribute of the impacted entry (and two other attributes, too : pwdGraceUseTime
and pwdAccountLockedTime. As we have 2 PPolicies, the attribute deletion will be
requested twice, in one single MOD operation. The second DEL modification will
then fail, leading to the rejection of the modification.

To make it a bit more complex, the pwdFailureTime was updated on the slave, not
replicated (it's a slave), and the password update was done on the master, so
the failure was on the slave, as the master was pushing the modification to it.
At the end, the two servers were not anymore in sync.

The reason for this failure was that the code in charge of checking the MOD
request, in ppolicy.c, lines 1575 to 1666, aren't checking if a DEL of one of
the three attributes is already present in the list of MODIFICATION.

Howard's suggestion to get this fix is to replace this code :

    got_del_fail = 1;
    if ( !a_fail )
        drop = 1;

by :

    if ( !a_fail || got_del_fail ) { 
        drop = 1;
    } else { 
        got_del_fail = 1; 
    }
Comment 1 Howard Chu 2015-07-10 13:05:30 UTC
changed notes
changed state Open to Test
moved from Incoming to Software Bugs
Comment 2 Quanah Gibson-Mount 2015-07-28 15:47:55 UTC
changed notes
changed state Test to Release
Comment 3 OpenLDAP project 2015-08-18 17:41:40 UTC
fixed in master
fixed in RE25
fixed in RE24 (2.4.42)
Comment 4 Quanah Gibson-Mount 2015-08-18 17:41:40 UTC
changed notes
changed state Release to Closed