[python-ldap] Modlist with a replace sometimes fails

[Petr Spacek]

On 3.3.2016 23:13, Michael Ströder wrote:
> William wrote:
>> On Thu, 2016-03-03 at 16:32 +0100, Michael Ströder wrote:
>>> William wrote:
>>>> I never heard back about whether the below patch is acceptable. I do not
>>>> change
>>>> the default behaviour, only add the ability to use MOD_REPLACE if the user
>>>> wishes
>>>> it.
>>> Even though this small change does not change the default behaviour it might be
>>> actually used and people will ask here when running into problems. We had
>>> discussions about that function before. I suspect your patch will open a can of
>>> worms leading to more patches for upcoming corner-cases. Also I don't have a
>>> test server running 389-DS. So it's hard for me to test corner-cases.
>>
>> But people can also use delete_s? modrdn_s? They can even use mod_replace in
>> modify if they build the list themself.
>> People will always be able to shoot themselves with your code, and can then ask
>> questions like "why did this not work".
> 
> Note that I always stayed away from implementing a object-LDAP-mapper for the
> very same reason.
> 
>> This is the point of clear, documentation.
> 
> And that's why I've added a clear interop note.
> 
>>> So if this is an urgent need in your project then you can easily overload this
>>> function with your own implementation. Even with your patch you have to touch
>>> your code.
>>
>> Yes, but I'll need to overload all of the modlist building function: Which is
>> quite excessive to maintain ....
> 
> 1. This function was not changed for years. So it's not hard to maintain a local
> fork in your code base.
> 
> 2. It will give you more flexibility for your needs. I suspect that there will
> be more modifications needed for your LDAP server deployment later.
> 
> Sometimes I forked some python-ldap code in web2ldap or somewhere else to test
> what's really needed in the long run. If it's really mature I port it back to
> python-ldap (can take some time).
> 
>>> In general it seems that this function might not fit everybody's needs. So I'll
>>> add an interop note in the docs about this:
>>>
>>>    .. note::
>>>       Replacing attribute values is always done with a
>>>       :py:const:`ldap.MOD_DELETE`/:py:const:`ldap.MOD_ADD` pair instead of
>>>       :py:const:`ldap.MOD_REPLACE` to work-around potential issues with
>>>       attributes for which no EQUALITY matching rule are defined in the
>>>       server's subschema.  This works correctly in most situations but
>>>       rarely fails with some LDAP servers implementing (schema) checks on
>>>       transient state entry during processing the modify operation.
>>
>> Which servers have the issue with MOD_REPLACE in question?
> 
> Several in case the attribute does not have an EQUALITY matching rule.
> 
>> I don't believe that 389-ds is one of them ...
> 
> Maybe. I cannot test.

Feel free to play with this one:
ldap://ipa.demo1.freeipa.org
BIND DN: uid=admin,cn=users,cn=accounts,dc=demo1,dc=freeipa,dc=org
BIND password: Secret123

The server is wiped clean every day at 05:00 UTC.

Petr Spacek @ Red Hat


>>> P.S.: IMO 389-DS should be fixed.
>> This is a tough request. The value in question is for database cache sizing: It
>> would be "silly" to allow it to be deleted, as when it's deleted it would have to
>> set a default value of some kind.
> 
> Note that a MOD_DELETE/MOD_ADD pair should not result in an attribute to be
> completely removed in the *final* state of an entry.
> 
> See also:
> 
> https://tools.ietf.org/html/rfc4511#section-4.6
> 
>      [..] While individual
>      modifications may violate certain aspects of the directory schema
>      (such as the object class definition and Directory Information Tree
>      (DIT) content rule), the resulting entry after the entire list of
>      modifications is performed MUST conform to the requirements of the
>      directory model and controlling schema [RFC4512].
> 
>> I believe that openldap has similar restrictions on deletion of some values in
>> their cn=config partition, but I don't run openldap so I cannot comment on what
>> they are. 
> 
> AFAICS OpenLDAP does not perform object class schema check on intermediate state
> of an entry. It does schema checking on the final state of an entry after
> applying all modifications. And IMHO that's how it should work.
> 
> Ciao, Michael.