Full_Name: Version: REL_ENG_2_1 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.224.170.55) OpenLDAP usually is very strict regarding schema parsing but provides some flags to be more liberal (constants LDAP_SCHEMA_ALLOW_* in ldap_schema.h). But even if LDAP_SCHEMA_ALLOW_ALL is used e.g. the following object class definition is not accepted: objectClasses: ( inetsubscriber-oid NAME 'inetSubscriber' SUP top AUXILIARY MAY ( inetSubscriberAccountId $ inetSubscriberChallenge $ inetSubscriberResponse ) X-ORIGIN 'Nortel subscriber interoperability') Yes, this definition does not provide a proper OID which violates LDAPv3 standard. But unfortunately most LDAP servers contain definitions like this...
I believe the older code allowed these definitions, but with rev 1.42 of schemaparse.c this behavior was removed, so valid OIDs are always required. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support > -----Original Message----- > From: owner-openldap-bugs@OpenLDAP.org > [mailto:owner-openldap-bugs@OpenLDAP.org]On Behalf Of > michael@stroeder.com > Sent: Tuesday, July 30, 2002 5:11 AM > To: openldap-its@OpenLDAP.org > Subject: Liberal parsing of schema elements (ITS#1996) > > > Full_Name: > Version: REL_ENG_2_1 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (62.224.170.55) > > > OpenLDAP usually is very strict regarding schema parsing but > provides some flags > to be more liberal (constants LDAP_SCHEMA_ALLOW_* in ldap_schema.h). > > But even if LDAP_SCHEMA_ALLOW_ALL is used e.g. the following object class > definition is not accepted: > > objectClasses: ( inetsubscriber-oid NAME 'inetSubscriber' SUP top > AUXILIARY MAY ( inetSubscriberAccountId $ inetSubscriberChallenge $ > inetSubscriberResponse ) X-ORIGIN 'Nortel subscriber interoperability') > > Yes, this definition does not provide a proper OID which violates LDAPv3 > standard. But unfortunately most LDAP servers contain definitions > like this... >
Howard Chu wrote: > I believe the older code allowed these definitions, Is it accepted in REL_ENG_2? > but with rev 1.42 > of schemaparse.c this behavior was removed, so valid OIDs are always > required. Please add the liberal behaviour again even though this might hurt your "LDAPv3 eyes". These kind of pseudo-OIDs "objectClassName-oid" are used in Netscape/iPlanet Directory Server and Novell eDirectory. It will be unpossible to implement schema-aware LDAP applications with the current behaviour. IMHO an application should treat OIDs of object classes opaque anyway. Therefore it would not hurt. Ciao, Michael.
To prevent garbage out, we prevent garbage in. If someone takes the time to allow garbage in (liberal in what you accept) in a manner which doesn't cause garbage out (strict in what you send), I'm fine with allowing such into the distribution. Patches welcomed. Kurt At 05:10 AM 2002-07-30, michael@stroeder.com wrote: >Full_Name: >Version: REL_ENG_2_1 >OS: Linux >URL: ftp://ftp.openldap.org/incoming/ >Submission from: (NULL) (62.224.170.55) > > >OpenLDAP usually is very strict regarding schema parsing but provides some flags >to be more liberal (constants LDAP_SCHEMA_ALLOW_* in ldap_schema.h). > >But even if LDAP_SCHEMA_ALLOW_ALL is used e.g. the following object class >definition is not accepted: > >objectClasses: ( inetsubscriber-oid NAME 'inetSubscriber' SUP top >AUXILIARY MAY ( inetSubscriberAccountId $ inetSubscriberChallenge $ >inetSubscriberResponse ) X-ORIGIN 'Nortel subscriber interoperability') > >Yes, this definition does not provide a proper OID which violates LDAPv3 >standard. But unfortunately most LDAP servers contain definitions like this...
Kurt D. Zeilenga wrote: > To prevent garbage out, we prevent garbage in. I understand that OpenLDAP is a reference implementation of LDAPv3 and therefore the main goal is to strictly adhere to the standards. But many people using it as a base for developing client apps accessing other LDAP servers violating the standard (Netscape/iPlanet DS, Novell eDirectory, Domino/LDAP R5, etc.). Regarding this specific issue here you already have some constants to allow a more liberal schema element parsing. That's what I suggest to leverage. Off course using these flags makes the application responsible for sanitizing the data / handle tricky situations if necessary. Note that I do *not* vote here to make the schema parsing on the server-side more liberal. I'm solely talking about client-side parsing in my own apps. > If someone takes the time to allow garbage in (liberal in > what you accept) in a manner which doesn't cause garbage > out (strict in what you send), I'm fine with allowing > such into the distribution. Patches welcomed. Well, this really depends on what you expect the application to send. As I said before IMHO schema-aware applications should not send an OID in any case. OIDs should be treated as opaque index to a local schema registry (except some hard-coded LDAP syntaxes). That's how I'm currently designing it for python-ldap. The attribute type and object class names are what appear in LDAPRequests sent to the LDAP server. Ciao, Michael.
I misunderstood the nature of the problem. The client library ALLOW flags, if properly enabled, should be able to parse these non-conformant values. If they aren't working, that's a bug. Patches welcomed. Of course, clients must (as in MUST, per RFC 2251) not send non-conformant values to servers. But most clients don't re-send values they read from servers. If they do, they are responsible for implementing the "strict in what is sent" part of this. Kurt At 02:53 PM 2002-07-30, michael@stroeder.com wrote: >Kurt D. Zeilenga wrote: >> To prevent garbage out, we prevent garbage in. > >I understand that OpenLDAP is a reference implementation of LDAPv3 >and therefore the main goal is to strictly adhere to the standards. > >But many people using it as a base for developing client apps >accessing other LDAP servers violating the standard >(Netscape/iPlanet DS, Novell eDirectory, Domino/LDAP R5, etc.). > >Regarding this specific issue here you already have some constants >to allow a more liberal schema element parsing. That's what I >suggest to leverage. Off course using these flags makes the >application responsible for sanitizing the data / handle tricky >situations if necessary. > >Note that I do *not* vote here to make the schema parsing on the >server-side more liberal. I'm solely talking about client-side >parsing in my own apps. > >> If someone takes the time to allow garbage in (liberal in >> what you accept) in a manner which doesn't cause garbage >> out (strict in what you send), I'm fine with allowing >> such into the distribution. Patches welcomed. > >Well, this really depends on what you expect the application to >send. As I said before IMHO schema-aware applications should not >send an OID in any case. OIDs should be treated as opaque index to >a local schema registry (except some hard-coded LDAP syntaxes). >That's how I'm currently designing it for python-ldap. The >attribute type and object class names are what appear in >LDAPRequests sent to the LDAP server. > >Ciao, Michael.
Kurt D. Zeilenga wrote: > I misunderstood the nature of the problem. The > client library ALLOW flags, if properly enabled, > should be able to parse these non-conformant > values. If they aren't working, that's a bug. > Patches welcomed. Any progress on this? Unfortunately I'm not a C programmer. I looked at the OpenLDAP code and AFAICS there is code to allow non-numeric OIDs if the proper ALLOW flag is set. The author of the relevant parts in python-ldap double-checked that the ALLOW flags are properly passed to OpenLDAP's schema parsing functions. But even with LDAP_SCHEMA_ALLOW_ALL the parsing chokes on e.g. this line (Python exception instance displayed here): ldap.schema.SCHERR_NODIGIT: (5, "( pilotOrganization-OID NAME 'pilotOrganization' DESC 'Standard ObjectClass' SUP 'top' MUST ( objectclass $ ou $ o ) MAY ( aci $ buildingName $ businessCategory $ description $ destinationIndicator $ facsimileTelephoneNumber $ internationalIsdnNumber $ l $ physicalDeliveryOfficeName $ postOfficeBox $ postalAddress $ postalCode $ preferredDeliveryMethod $ registeredAddress $ searchGuide $ seeAlso $ st $ street $ telephoneNumber $ teletexTerminalIdentifier $ telexNumber $ userPassword $ x121Address ) )") > Of course, clients must (as in MUST, per RFC 2251) > not send non-conformant values to servers. Yes. My policy usually is: Allow garbage in if deterministic in some way, always produce compliant values as output. Ciao, Michael.
At 04:04 AM 2002-08-08, michael@stroeder.com wrote: >Kurt D. Zeilenga wrote: >> I misunderstood the nature of the problem. The >> client library ALLOW flags, if properly enabled, >> should be able to parse these non-conformant >> values. If they aren't working, that's a bug. >> Patches welcomed. > >Any progress on this? I haven't heard of any. Kurt
moved from Incoming to Software Bugs
> Kurt D. Zeilenga wrote: >> I misunderstood the nature of the problem. The >> client library ALLOW flags, if properly enabled, >> should be able to parse these non-conformant >> values. If they aren't working, that's a bug. >> Patches welcomed. The code parses the string just fine and returns a valid LDAPObjectClass result. It just happens to leave a non-zero error code set as well, left over from its attempt to find a numeric OID. With the ALLOW flags set, that code is ignored and the parse continues. Since the return value is non-NULL Python should not be treating this as a failure. > > Any progress on this? > > Unfortunately I'm not a C programmer. I looked at the OpenLDAP > code and AFAICS there is code to allow non-numeric OIDs if the > proper ALLOW flag is set. > > The author of the relevant parts in python-ldap double-checked > that the ALLOW flags are properly passed to OpenLDAP's schema > parsing functions. > > But even with LDAP_SCHEMA_ALLOW_ALL the parsing chokes on e.g. > this line (Python exception instance displayed here): > > ldap.schema.SCHERR_NODIGIT: (5, "( pilotOrganization-OID NAME > 'pilotOrganization' DESC 'Standard ObjectClass' SUP 'top' MUST ( > objectclass $ ou $ o ) MAY ( aci $ buildingName $ > businessCategory $ description $ destinationIndicator $ > facsimileTelephoneNumber $ internationalIsdnNumber $ l $ > physicalDeliveryOfficeName $ postOfficeBox $ postalAddress $ > postalCode $ preferredDeliveryMethod $ registeredAddress $ > searchGuide $ seeAlso $ st $ street $ telephoneNumber $ > teletexTerminalIdentifier $ telexNumber $ userPassword $ > x121Address ) )")
Howard Chu wrote: > > The code parses the string just fine and returns a valid LDAPObjectClass result. > It just happens to leave a non-zero error code set as well, left over from its > attempt to find a numeric OID. With the ALLOW flags set, that code is ignored > and the parse continues. Since the return value is non-NULL Python should not be > treating this as a failure. IMHO the error code should be zero if everything went well. It's called error code... Anyway I've implemented my own parser in pure Python and switched off using the schema API of OpenLDAP from python-ldap. Ciao, Michael.
At 04:50 AM 2002-08-29, michael@stroeder.com wrote: >IMHO the error code should be zero if everything went well. That would violate the errno model used in the LDAP API. The library should never clear the errno. Kurt
changed state Open to Suspended moved from Software Bugs to Incoming
changed notes changed state Suspended to Closed
moved from Incoming to Archive.Incoming
python bug