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