[python-ldap] Modlist with a replace sometimes fails

[Michael Ströder]

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.

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160303/eaef2ecb/attachment.bin>