openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Re: (ITS#5517) add superclass of existing class fails
by Kurt＠OpenLDAP.org 24 May '08

24 May '08

On May 24, 2008, at 2:18 AM, ando(a)sys-net.it wrote: > I believe the actual implementation should be... implementation > dependent :), provided it is consistent. I agree there is a slight inconsistency. A client can delete a listed superclass but not add an superclass of a listed attribute. One could argue that both be considered invalid operations. However, it would be reasonable to consider an add of an unlisted superclass and a delete of a listed superclass to be valid. However, a add of an already listed class should be invalid and a delete of a unlisted class should always be invalid. -- Kurt

1 0

Re: (ITS#5517) add superclass of existing class fails
by Kurt＠OpenLDAP.org 24 May '08

24 May '08

On May 24, 2008, at 2:37 PM, h.b.furuseth(a)usit.uio.no wrote: > 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. Maybe in the RFCs. > objectClass has EQUALITY matching rule > objectIdentifierMatch, which does not follow the object class > inheritance chain. Yes, but objectClass is quite special (despite being a userApplications attribute). For instance, (objectClass=*) is to match DSEs which don't have an objectClass attribute. Likewise, objectClass=foo can match objectClass attributes which don't explicitly contain foo. > 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. You are reading 3.3 as if it said "SHALL be added (by the server)". It doesn't say "SHALL be added (by the server). It says "SHALL be implicitly added" (presumedly by the server). This was discussed during LDAPbis discussions. As the Editor of RFC 4512, I can say that it was my intent to allow servers to merely treat superclasses as being present. > Instead slapd should add the missing classes to the actual object, Doing so is problematic. A client which adds B then deletes B would be surprised by non-net-zero result of the operation(s). > just like it adds some other attribute/values > implicitly (createTimestamp, subschemaSubentry, etc). These are operational attributes. ObjectClass is an userApplications attribute. Servers should not muck with the values of userApplication attributes. > 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 > >

1 0

Re: (ITS#5517) add superclass of existing class fails
by Kurt＠OpenLDAP.org 24 May '08

24 May '08

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

1 0

Re: (ITS#5517) add superclass of existing class fails
by h.b.furuseth＠usit.uio.no 24 May '08

24 May '08

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

1 0

Re: (ITS#5517) add superclass of existing class fails
by h.b.furuseth＠usit.uio.no 24 May '08

24 May '08

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

1 0

Re: (ITS#5517) add superclass of existing class fails
by ando＠sys-net.it 24 May '08

24 May '08

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

1 0

Re: (ITS#5517) add superclass of existing class fails
by ando＠sys-net.it 24 May '08

24 May '08

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

1 0

Re: (ITS#5505) Attribute value for 'modifiersName' in case of overlays
by ando＠sys-net.it 24 May '08

24 May '08

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

1 0

Re: (ITS#5517) add superclass of existing class fails
by ando＠sys-net.it 24 May '08

24 May '08

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

1 0

Re: (ITS#5527) Segmentation fault in dynlist.c
by hyc＠symas.com 23 May '08

23 May '08

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 have recieved a bug report about a segmentation fault using dynlist. You can > find the bug report at: > > http://bugs.launchpad.net/bugs/218734 > > If you have any questions please feel free to ask. I was able to reproduce your crash in 2.4.7 but not in 2.4.9. This ITS will be closed. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs