Re: (ITS#5517) add superclass of existing class fails
by Kurt＠OpenLDAP.org
On May 18, 2008, at 11:09 AM, h.b.furuseth(a)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.
Yes, A is implicitly present (by implicit add).
> OTOH it allows replace(objectClass: <A, B>), and after that it allows
> delete(objectClass: A). This is inconsistent.
This can be argued to be incorrect. It is improper to attempt to
delete a superclass of any listed class.
> If the objectClass attribute contains B, does it "really" contain A as
> well?
If provided by the client, yes. Otherwise A is implicitly present due
to B.
When a client adds B then deletes B, its a net zero result. If A were
actually added by the server, the delete of B would either leave A
behind or be invalid (such as when A is abstract).
> I couldn't find such a statement in the RFCs,
The RFCs are someone vague here.
> so my guess is that add(objectClass: A) should be allowed.
Adding A when a subclass is present is just as invalid as deleting A
when a subclass is present. Both should result in errors.
> Though I haven't looked
> all that hard.
>
> Example:
>
> ldapadd -cx <<'EOF'
> # Create initial object
> dn: c=NO
> objectClass: friendlyCountry
> c: NO
> co: Norway
>
> # error
> dn: c=NO
> changetype: modify
> add: objectClass
> objectClass: top
> -
>
> # error
> dn: c=NO
> changetype: modify
> add: objectClass
> objectClass: country
> -
>
> # success
> dn: c=NO
> changetype: modify
> replace: objectClass
> objectClass: top
> objectClass: country
> objectClass: friendlyCountry
> -
>
> # success
> dn: c=NO
> changetype: modify
> delete: objectClass
> objectClass: top
> -
>
> # success
> dn: c=NO
> changetype: modify
> delete: objectClass
> objectClass: country
> -
> EOF
>
>
14 years, 10 months
Re: (ITS#5517) add superclass of existing class fails
by h.b.furuseth＠usit.uio.no
h.b.furuseth(a)usit.uio.no writes:
> This looks like a bug to me. objectClass has EQUALITY matching rule
> objectIdentifierMatch, which does not follow the object class
> inheritance chain. (...)
>
> What makes slapd work is that it also disobeys RFC 4512 section 3.3:
Oops, I meant the opposite: It's 1st bug which slapd with 2nd bug work.
--
Hallvard
14 years, 10 months
Re: (ITS#5517) add superclass of existing class fails
by h.b.furuseth＠usit.uio.no
ando(a)sys-net.it writes:
> 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.
This looks like a bug to me. objectClass has EQUALITY matching rule
objectIdentifierMatch, which does not follow the object class
inheritance chain. See RFC 4517 section 4.2.26. RFC 4512 section 3.3
(the 'objectClass' attribute) does not special-case this.
What makes slapd work is that it also disobeys RFC 4512 section 3.3:
"When creating an entry or adding an 'objectClass' value to an entry,
all superclasses of the named classes SHALL be implicitly added as
well if not already present."
This doesn't say the classes shall be considered to be implicitly
present, like slapd does. Instead slapd should add the missing classes
to the actual object, just like it adds some other attribute/values
implicitly (createTimestamp, subschemaSubentry, etc).
I don't know what to do about it now though. Will replication work
between current servers and servers which obeys the RFCs? Is this a RE25
fix, so we should stay with fixed like previously suggested in RE24? Or
yet another thing to do with the last RE23, for the sake of replication?
--
Hallvard
14 years, 10 months
Re: (ITS#5517) add superclass of existing class fails
by ando＠sys-net.it
ando(a)sys-net.it wrote:
> ando(a)sys-net.it wrote:
>> h.b.furuseth(a)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(a)sys-net.it
---------------------------------------
14 years, 10 months
Re: (ITS#5517) add superclass of existing class fails
by ando＠sys-net.it
ando(a)sys-net.it wrote:
> h.b.furuseth(a)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(a)sys-net.it
---------------------------------------
14 years, 10 months
Re: (ITS#5505) Attribute value for 'modifiersName' in case of overlays
by ando＠sys-net.it
ando(a)sys-net.it wrote:
>> Just a feature request for convenience:
>>
>> Would it be possible to set the value of attribute 'modifiersName' to the
>> DN of
>> the overlays' configuration entry under cn=config if an entry was modified
>> by an
>> overlay? In this case one would have a direct link to the configuration if
>> needed. Currently 'cn=<overlay name>' (e.g cn=Referential Integrity
>> Overlay) is
>> added which does not refer to an existing entry at all.
>
> Technically, I don't see any problem, except that overlays (and software
> modules, in general) do not hold a direct reference to their config
> entry's DN, if any (e.g. when back-config is not in use, the data
> structure is in place, but not in LDIF form; please correct me if I'm
> wrong). I wonder whether exposing such detail makes sense, or risks
> breaking any security. Probably I'm getting paranoid...
As a quick fix to your legitimate issue, I've added to HEAD the
refint_modifiersname parameter that allows to customize the name used
for internal modifications. Please test.
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(a)sys-net.it
---------------------------------------
14 years, 10 months
Re: (ITS#5517) add superclass of existing class fails
by ando＠sys-net.it
h.b.furuseth(a)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).
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(a)sys-net.it
---------------------------------------
14 years, 10 months
Re: (ITS#5526) Another segmentation fault
by hyc＠symas.com
quanah(a)zimbra.com wrote:
> --On Friday, May 23, 2008 9:02 AM +0000 zulcss(a)ubuntu.com wrote:
>
>> Full_Name: Chuck Short
>> Version: 3.2.7
>> OS: Ubuntu
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (82.142.121.161)
>>
>>
>> Hello,
>>
>> We received another report of a segmentation fault in openldap 3.2.7. The
>> bug report with the test case can be found at:
>>
>> http://bugs.launchpad.net/bugs/234196
>>
>> If you have any questions please let me know.
>
> Sure. What is OpenLDAP 3.2.7? And the bug reported here was already fixed
> in OpenLDAP 2.4.9 IIRC. Please validate bugs against 2.4.9 before filing
> an ITS.
Actually no, this particular bug was still present in 2.4.9. A patch is in
HEAD and still needs testing. Some of the other recently filed ones were
already fixed though.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
14 years, 10 months
Re: (ITS#5526) Another segmentation fault
by quanah＠zimbra.com
--On Friday, May 23, 2008 8:09 AM -0700 Quanah Gibson-Mount
<quanah(a)zimbra.com> wrote:
> --On Friday, May 23, 2008 9:02 AM +0000 zulcss(a)ubuntu.com wrote:
>
>> Full_Name: Chuck Short
>> Version: 3.2.7
>> OS: Ubuntu
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (82.142.121.161)
>>
>>
>> Hello,
>>
>> We received another report of a segmentation fault in openldap 3.2.7. The
>> bug report with the test case can be found at:
>>
>> http://bugs.launchpad.net/bugs/234196
>>
>> If you have any questions please let me know.
>
> Sure. What is OpenLDAP 3.2.7? And the bug reported here was already
> fixed in OpenLDAP 2.4.9 IIRC. Please validate bugs against 2.4.9 before
> filing an ITS.
Okay, ignore me. I was thinking of a different assertion failure fixed by
2.4.9. :P
But 3.2.7 still is not a valid OpenLDAP release. ;)
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
14 years, 10 months