Re: ldap.modlist.modifyModlist() (resent to list)

[Michael S. <mi...@st...>]

Paul Wankadia wrote:
> On Fri, Sep 19, 2008 at 6:12 PM, Michael Ströder <mi...@st...> wrote:
> 
>>> The current implementation of modifyModlist() clashed with some ACLs
>>> because it touches too many values. :/
>> I don't fully understand. Do you have ACLs based on certain attribute
>> values? It would be probably a good idea to mention these issues in the
>> docs.
> 
> Access to objectClass is restricted, for example, so it's necessary to
> be surgical.

Is access to attribute 'objectClass' restricted as a whole? Or do you
have ACLs based on certain attribute values (object class names in this
case)? Only the latter case seems to be a problem to me.

>>>       if old_values != new_values:
>>>         modify.append((ldap.MOD_REPLACE, attr, list(new_values)))
>> The problem with MOD_REPLACE or with only deleting/adding certain
>> attribute values is that it needs EQUALITY matching rules to be
>> implemented at the server-side for all syntaxes of attributes to be
>> modified. That's not the case for e.g. jpegPhoto (or even attribute
>> postalAddress on some servers).
> 
> Do you happen to know whether OpenLDAP has any problems in this regard?

Actually I started with an implementation of modifyModlist() in web2ldap
which did almost exactly what you propose. But in general it turned out
not to be usable. It always depends on the attributes you're dealing
with. Check the subschema on your server.

>> In web2ldap I have a modified function modifyModlist() which examines
>> the subschema for determining whether the attribute type has an EQUALITY
>> matching rules assigned and whether this particular matching rule is
>> really listed in the subschema.
> 
> What does it do then?

It falls back to applying MOD_DELETE/MOD_ADD to the whole attribute.

Ciao, Michael.