[python-ldap] Modlist with a replace sometimes fails

[William]

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

This is the point of clear, documentation.

So perhaps consider the patch, and also expand the documentation around the
modlist functions to say "the default is this and WHY" and what the risks of
mod_replace are. People should be able to take responsibility for their own
actions.

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

> 
> 
> 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? I don't believe that
389-ds is one of them ...

> 
> 
> Ciao, Michael.
> 
> 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. Then there is the question of what is the
default etc. There is also the question of whether the team would allow such a
"risky" change to be accepted. 

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. 


-- 
William <william at blackhats.net.au>