Re: (ITS#5517) add superclass of existing class fails

[ando@sys-net.it]

ando@sys-net.it wrote:
> h.b.furuseth@usit.uio.no wrote:
>> Full_Name: Hallvard B Furuseth
>> Version: HEAD
>> OS: Linux
>> URL: 
>> Submission from: (NULL) (129.240.6.233)
>> Submitted by: hallvard
>>
>>
>> If objectclass B is a subclass of A, and an entry contains objectclass B
>> but not A, slapd returns attributeOrValueExists to a request to add A.
>> OTOH it allows replace(objectClass: <A, B>), and after that it allows
>> delete(objectClass: A).  This is inconsistent.
>>
>> If the objectClass attribute contains B, does it "really" contain A as
>> well?  I couldn't find such a statement in the RFCs, so my guess is
>> that add(objectClass: A) should be allowed.  Though I haven't looked
>> all that hard.
> 
> I believe the actual implementation should be... implementation 
> dependent :), provided it is consistent.  Right now, the issue you 
> noticed is caused by the fact that the presence of the value being added 
> is checked by using the objectClass attribute equality rule implemented 
> in objectSubClassMatch(), which (correctly) returns a match both for 
> exact and inherited match.  However, this does not allow to discriminate 
> the actual presence of an objectClass from its inherited presence.  We 
> should either:
> 
> a) use a separate matching rule when checking for value presence, or
> 
> b) always remove superior objectClasses, and transparently ignore any 
> attempt to add them to an entry (the operation succeeds, but nothing is 
> actually written).
> 
> In any case, the code as is now seems to be inconsistent, as it does not 
> allow a modification that should be perfectly legitimate, regardless of 
> how it is actually dealt with by the implementation.
> 
> I vote in favor of option (b).

Probably, the "right" fix requires to extend the concept of equality 
match, to distinguish between "match" in the sense of filtering and 
"match" in the sense of literal match.  Something like that already 
occurs: see SLAP_MR_VALUE_OF_ASSERTION_SYNTAX vs. 
SLAP_MR_VALUE_OF_ATTRIBUTE_SYNTAX.  The issue right now is caused by the 
fact that comparing present values with the asserted one causes 
objectSubClassMatch() to check for match including superiors.  Match 
functions should be able to return an indication about whether the match 
was literal or not, sort of a return flag indicating if the match was 
SLAP_MR_VALUE_OF_ATTRIBUTE_SYNTAX or SLAP_MR_VALUE_OF_ASSERTION_SYNTAX. 
  This will probably require some significant API change in the match 
routines, unless the related information can be safely ORed to the 
return value.

p.



Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office:  +39 02 23998309
Mobile:  +39 333 4963172
Email:   pierangelo.masarati@sys-net.it
---------------------------------------