[Date Prev][Date Next] [Chronological] [Thread] [Top]

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



ando@sys-net.it wrote:
> 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.

Quick hack along the lines of option (a):

diff -u -r1.65 mods.c
--- servers/slapd/mods.c        7 Jan 2008 23:20:08 -0000       1.65
+++ servers/slapd/mods.c        24 May 2008 13:09:44 -0000
@@ -99,7 +99,13 @@
                  * server (whether from LDAP or from the underlying
                  * database).
                  */
-               flags = SLAP_MR_EQUALITY | SLAP_MR_VALUE_OF_ASSERTION_SYNTAX;
+               if ( a->a_desc == slap_schema.si_ad_objectClass ) {
+                       /* Needed by ITS#5517 */
+                       flags = SLAP_MR_EQUALITY | SLAP_MR_VALUE_OF_ATTRIBUTE_SYNTAX;
+
+               } else {
+                       flags = SLAP_MR_EQUALITY | SLAP_MR_VALUE_OF_ASSERTION_SYNTAX;
+               }
                 if ( mod->sm_nvalues ) {
                         flags |= SLAP_MR_ASSERTED_VALUE_NORMALIZED_MATCH |
                                 SLAP_MR_ATTRIBUTE_VALUE_NORMALIZED_MATCH;

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