[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
(ITS#8184) MOD operation with a double delete of a pwdFailureTime attribute
- To: openldap-its@OpenLDAP.org
- Subject: (ITS#8184) MOD operation with a double delete of a pwdFailureTime attribute
- From: elecharny@apache.org
- Date: Thu, 02 Jul 2015 10:58:56 +0000
- Auto-submitted: auto-generated (OpenLDAP-ITS)
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;
}