Full_Name: Ganesan R Version: 2.1.9 OS: Debian GNU/Linux 3.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.107.253.38) Hi, All versions of openldap allow the creation of a dn with a cn attribute even if the objectclass doesn't include a cn. For example, I can add the following object without an error. --- dn: cn=mycountry,dc=mycompany,dc=com objectclass: country c: mycountry --- In case of a locality, which does not even locality as a MUST attribute, the following ldif can be added successfully. --- dn: cn=mylocality,dc=mycompany,dc=com objectclass: locality --- This bug exists for any objectclass that doesn't have cn as a must attribute. You can also add a locality without specifying 'l' in the list of attributes, since l is not a MUST attribute. I don't know if LDAP allows creation of an object with no attribute being present for the RDN. --- dn: l=mylocality,dc=mycompany,dc=com objectclass: locality --- Ganesan
changed state Open to Suspended moved from Incoming to Software Bugs
> Date: Wed, 18 Dec 2002 11:02:56 GMT > From: rganesan@vsnl.net > To: openldap-its@OpenLDAP.org > Subject: Invalid Add operations allowed > > Full_Name: Ganesan R > Version: 2.1.9 > OS: Debian GNU/Linux 3.0 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.107.253.38) > > > Hi, > > All versions of openldap allow the creation of a dn with a cn attribute even if > the objectclass doesn't include a cn. For example, I can add the following > object without an error. > > --- > dn: cn=mycountry,dc=mycompany,dc=com > objectclass: country > c: mycountry > --- > > In case of a locality, which does not even locality as a MUST attribute, > the following ldif can be added successfully. > > --- > dn: cn=mylocality,dc=mycompany,dc=com > objectclass: locality > --- > > This bug exists for any objectclass that doesn't have cn as a must attribute. > You can also add a locality without specifying 'l' in the list of attributes, > since l is not a MUST attribute. I don't know if LDAP allows creation of > an object with no attribute being present for the RDN. > > --- > dn: l=mylocality,dc=mycompany,dc=com > objectclass: locality > --- The right solution for this is adding rdn implicitly then it omitted in ldif, as IPlanet does on add/modrdn, and OpenLDAP does on modrdn. Btw, last example is correct in this case... we can add such entry, but when we search for it, we must get --- dn: l=mylocality,dc=mycompany,dc=com objectclass: locality l: mylocality #actually this added automatically by server #at object creation time. --- in the next case it's just essential to add rdn automatically _before_ schemacheck. --- dn: cn=mycountry,dc=mycompany,dc=com objectclass: country c: mycountry cn: mycountry #and this will be rejected by schemacheck. --- > Ganesan SMTP /Perece/.
changed notes changed state Suspended to Test
>> >> All versions of openldap allow the creation of a dn with a cn >> attribute even if the objectclass doesn't include a cn. For example, I >> can add the following object without an error. in RFC2251-6 I didn't find any esplicit mention of the fact that an attr in the rdn MUST be present in the entry in type or value. However, in " 4.7. Add Operation" of rfc 2251 I see - attributes: the list of attributes that make up the content of the entry being added. Clients MUST include distinguished values (those forming the entry's own RDN) in this list, the objectClass attribute, and values of any mandatory attributes of the listed object classes. Clients MUST NOT supply the createTimestamp or creatorsName attributes, since these will be generated automatically by the server. which means that slapd is not checking the consistency of an entry when added. It does when the rdn is modified (e.g. keeps the entry's values in sync with those of the rdn). I guess we need to enforce this check at add. Comments? P. -- Pierangelo Masarati mailto:pierangelo.masarati@sys-net.it
Greetings. Pierangelo Masarati wrote: > > >> > >> All versions of openldap allow the creation of a dn with a cn > >> attribute even if the objectclass doesn't include a cn. For example, I > >> can add the following object without an error. > > in RFC2251-6 I didn't find any esplicit mention of the fact > that an attr in the rdn MUST be present in the entry in type > or value. However, in " 4.7. Add Operation" of rfc 2251 I see > > - attributes: the list of attributes that make up the content of the > entry being added. Clients MUST include distinguished values > (those forming the entry's own RDN) in this list, the objectClass > attribute, and values of any mandatory attributes of the listed > object classes. Clients MUST NOT supply the createTimestamp or > creatorsName attributes, since these will be generated > automatically by the server. > > which means that slapd is not checking the consistency of an entry > when added. It does when the rdn is modified (e.g. keeps the entry's > values in sync with those of the rdn). I guess we need to enforce > this check at add. As I already say, Iplanet (and it's ancestor - Sun Directory Server) enforces such check at add. It even adds dn-forming attribute/value to entry if no values for this attribute is given. And I can say from my experience with it and with OpenLDAP, it's much easier to maintain base in consistent state when dn-forming attrs added to entry automatically when needed. Also I can say what RFC2251-6 doesn't disallow such operations at server side, altough it isn't requires that, so slapd _can_ perform this and it still be rfc-compliant. I think best solution is adding a conf option, saying what to do when such add operation comes: - accept operation - it's current behavor; - reject operation - btw, which error code must be returned? - add missing value (computed from entry DN) SMTP /Perece/.
> As I already say, Iplanet (and it's ancestor - Sun Directory Server) > enforces such check at add. It even adds dn-forming attribute/value to > entry if no values for this attribute is given. > And I can say from my experience with it and with OpenLDAP, > it's much easier to maintain base in consistent state > when dn-forming attrs added to entry automatically when needed. > Also I can say what RFC2251-6 doesn't disallow such operations > at server side, altough it isn't requires that, so slapd _can_ > perform this and it still be rfc-compliant. > > I think best solution is adding a conf option, saying what to do > when such add operation comes: I'm not in favour of this. The rule must be one, consisting in the correct interpretation of the standard track. > - accept operation - it's current behavor; If we agree this is not correct, I'd dispose of this option > - reject operation - btw, which error code must be returned? In my opinion this is the best option, although I'm already hearing weeps and cries "It worked until yesterday, why doesn't it work any more?". As for the error code, I propose constraintViolation, although objectClassViolation would be an alternative. > - add missing value (computed from entry DN) This might be a safe default, at the cost of doing something the user had not intended to. I just committed code that implements the two last options (the third is on by default, although I favor the second; to enable the first, #define BAILOUT in servers/slapd/add.c) Comments? -- Pierangelo Masarati mailto:pierangelo.masarati@sys-net.it
At 07:05 AM 1/29/2003, ando@sys-net.it wrote: >> - reject operation - btw, which error code must be returned? > >In my opinion this is the best option, although I'm already hearing >weeps and cries "It worked until yesterday, why doesn't it work any >more?". IMO, this is the "correct" behavior as AVAs chosen for the RDN of an entry are suppose to come from values of attributes of that entry. >As for the error code, I propose constraintViolation, >although objectClassViolation would be an alternative. Or noSuchAttribute. Kurt
oops... forgot to CC message... -------- Original Message -------- Subject: Re: Invalid Add operations allowed (ITS#2243) Date: Thu, 30 Jan 2003 10:01:40 +0300 From: ntb@mts.ru To: ando@sys-net.it References: <200301290656.h0T6u6AM095451@galois.openldap.org><36057.131.175.154.56.1043840823.squirrel@webmail.sys-net.it><3E37C7C8.F2525D88@mts.ru> <36299.131.175.154.56.1043852845.squirrel@webmail.sys-net.it> Greetings. Pierangelo Masarati wrote: > > > As I already say, Iplanet (and it's ancestor - Sun Directory Server) > > enforces such check at add. It even adds dn-forming attribute/value to > > entry if no values for this attribute is given. > > And I can say from my experience with it and with OpenLDAP, > > it's much easier to maintain base in consistent state > > when dn-forming attrs added to entry automatically when needed. > > Also I can say what RFC2251-6 doesn't disallow such operations > > at server side, altough it isn't requires that, so slapd _can_ > > perform this and it still be rfc-compliant. > > > > I think best solution is adding a conf option, saying what to do > > when such add operation comes: > > I'm not in favour of this. The rule must be one, consisting > in the correct interpretation of the standard track. > > > - accept operation - it's current behavor; > > If we agree this is not correct, I'd dispose of this option > > > - reject operation - btw, which error code must be returned? > > In my opinion this is the best option, although I'm already hearing > weeps and cries "It worked until yesterday, why doesn't it work any > more?". As for the error code, I propose constraintViolation, > although objectClassViolation would be an alternative. > > > - add missing value (computed from entry DN) > > This might be a safe default, at the cost of doing something > the user had not intended to. > > I just committed code that implements the two last options > (the third is on by default, although I favor the second; > to enable the first, #define BAILOUT in servers/slapd/add.c) > > Comments? Disposing current behavor is almost safe, but not in all cases. example from original message: --- dn: cn=mycountry,dc=mycompany,dc=com objectclass: country c: mycountry --- in with last option in effect (which is current default behavour after Your commit) this will produce: --- dn: cn=mycountry,dc=mycompany,dc=com objectclass: country c: mycountry cn: mycountry --- which is an objectClassViolation. So, schemacheck must be done _after_ adding attribute computed from DN. In this case first option - accept operation as is - can be used by people crying "Why it is stop working" as first aid. (or forever for some lazy admins, who prefer not to change current mechs such as scripts using ldap, samba settings, etc.. but want to proceed to newer versions) In last example from original ITS, on the contrary, adding a computed value will fix an entry, and moreover, it fix it transparently for mechanisms using/adding such entries. --- dn: l=mylocality,dc=mycompany,dc=com objectclass: locality --- will be: --- dn: l=mylocality,dc=mycompany,dc=com objectclass: locality l: mylocality --- which is correct. And one more example from me personally: --- dn: l=mylocality,dc=mycompany,dc=com objectclass: locality l: otherlocality --- in this case reurning constraintViolation is best choice, altough we can produce: --- dn: l=mylocality,dc=mycompany,dc=com objectclass: locality l: otherlocality l: mylocality --- and accept it. I think adding a value is best default (last example is an exception), altough rejecting operation is more "standard conforming". SMTP /Perece/.
At 11:10 PM 1/29/2003, ntb@mts.ru wrote: >example from original message: > >--- >dn: cn=mycountry,dc=mycompany,dc=com >objectclass: country >c: mycountry >--- As I noted to Ando, the above entry is invalid. An attempt to add such should result in an error such as noSuchAttribute. -- Kurt
> At 11:10 PM 1/29/2003, ntb@mts.ru wrote: >>example from original message: >> >>--- >>dn: cn=mycountry,dc=mycompany,dc=com >>objectclass: country >>c: mycountry >>--- > > As I noted to Ando, the above entry is invalid. An attempt > to add such should result in an error such as noSuchAttribute. ... which is now the current behavior of slapd. The only allowed cases, pending review, are: dn: ou=Guests,dc=my,dc=org objectClass: alias aliasedObjectName: ou=People,dy=my,dc=org and dn: ou=Guests,dc=my,dc=org objectClass: referral ref: ldap://ldap.your.org/ou=People,dc=my,dc=org which eventually (as exemplified in RFC3296) should be turned into dn: ou=Guests,dc=my,dc=org objectClass: referral objectClass: extensibleObject ou: Guests ref: ldap://ldap.your.org/ou=People,dc=my,dc=org and thus also comply with RFC2251. I've added a /* FIXME */ in this sense in servers/slapd/add.c Ando. -- Pierangelo Masarati mailto:pierangelo.masarati@sys-net.it
At 12:21 PM 1/30/2003, ando@sys-net.it wrote: >> At 11:10 PM 1/29/2003, ntb@mts.ru wrote: >>>example from original message: >>> >>>--- >>>dn: cn=mycountry,dc=mycompany,dc=com >>>objectclass: country >>>c: mycountry >>>--- >> >> As I noted to Ando, the above entry is invalid. An attempt >> to add such should result in an error such as noSuchAttribute. > >... which is now the current behavior of slapd. >The only allowed cases, pending review, are: > >dn: ou=Guests,dc=my,dc=org >objectClass: alias >aliasedObjectName: ou=People,dy=my,dc=org Invalid. Should have: ou: Guests as well as an additional objectClass (or DIT Content Rule) which allows ou to be present in the alias. >and > >dn: ou=Guests,dc=my,dc=org >objectClass: referral >ref: ldap://ldap.your.org/ou=People,dc=my,dc=org Invalid. Should have: ou: Guests as well as an additional objectClass (or DIT Content Rule) which allows ou to be present in the referral. >which eventually (as exemplified in RFC3296) should be turned into No. The client is responsible for providing a proper entry. The server is responsible for ensuring that no improper entry is added. The server should NOT turn an improper entry into a proper entry. >and thus also comply with RFC2251. > >I've added a /* FIXME */ in this sense in servers/slapd/add.c The fix is to remove the /* FIXME */ stuff. There are no special alias/referral cases here. Kurt
>>which eventually (as exemplified in RFC3296) should be turned into > > No. The client is responsible for providing a proper > entry. The server is responsible for ensuring that no > improper entry is added. The server should NOT turn > an improper entry into a proper entry. I meant *should be turned BY THE CLIENT into* (so that we can remove the special case treatment). > >>and thus also comply with RFC2251. >> >>I've added a /* FIXME */ in this sense in servers/slapd/add.c > > The fix is to remove the /* FIXME */ stuff. There are no > special alias/referral cases here. What about allowing a (smooth) transition? Ando -- Pierangelo Masarati mailto:pierangelo.masarati@sys-net.it
At 02:39 PM 1/30/2003, ando@sys-net.it wrote: >What about allowing a (smooth) transition? No transition is required for clients which conformed to the specification. Kurt
Could we make the non-BAILOUT behaviour (add RDN attributes not specified in the entry) a configure- or run-time option? Unfortunately we must deal with some clients, such as Active Directory, that do not always include the RDN attribute in the entry. -- Luke -- Luke Howard | PADL Software Pty Ltd | www.padl.com
> > Could we make the non-BAILOUT behaviour (add RDN attributes > not specified in the entry) a configure- or run-time option? > > Unfortunately we must deal with some clients, such as Active > Directory, that do not always include the RDN attribute in > the entry. Personally, I don't like it; however, it is currently a compile option: #undef BAILOUT in servers/slapd/add.c and you get the desired behavior. It can be easily turned into a config option, but I'd consider it confusing and misleading. Maybe it could be part of the "schemacheck off" option... P. -- Pierangelo Masarati mailto:pierangelo.masarati@sys-net.it
>> Could we make the non-BAILOUT behaviour (add RDN attributes >> not specified in the entry) a configure- or run-time option? >> >> Unfortunately we must deal with some clients, such as Active >> Directory, that do not always include the RDN attribute in >> the entry. > >Personally, I don't like it; however, it is currently >a compile option: #undef BAILOUT in servers/slapd/add.c >and you get the desired behavior. It can be easily turned I have done that (#undef BAILOUT) for the moment. However we would prefer to use an unmodified OpenLDAP tree where possible... >into a config option, but I'd consider it confusing and >misleading. Maybe it could be part of the "schemacheck off" >option... How about an undocumented option? :-) -- Luke -- Luke Howard | PADL Software Pty Ltd | www.padl.com
> >>> Could we make the non-BAILOUT behaviour (add RDN attributes >>> not specified in the entry) a configure- or run-time option? >>> >>> Unfortunately we must deal with some clients, such as Active >>> Directory, that do not always include the RDN attribute in >>> the entry. >> >>Personally, I don't like it; however, it is currently >>a compile option: #undef BAILOUT in servers/slapd/add.c >>and you get the desired behavior. It can be easily turned > > I have done that (#undef BAILOUT) for the moment. However we > would prefer to use an unmodified OpenLDAP tree where possible... I'm in favour of having both behaviors in the main tree, with a preference for the BAILOUT case > >>into a config option, but I'd consider it confusing and >>misleading. Maybe it could be part of the "schemacheck off" >>option... > > How about an undocumented option? :-) I'd prefer documented options. Since I understand there may be need for this "soft" case, and since this would harmonize with the behavior of existing implementations, I would not oppose a config option, with default to BAILOUT, of course. Ando. -- Pierangelo Masarati mailto:pierangelo.masarati@sys-net.it
I've reworked the RDN checks so that they are consistently applied to add, mod[r]dn, and modify operations. In the later case, the check prevents modification of the attribute of the entry in a manner inconsistent with the DN. The checks are disabled by "schemacheck off"... At 04:25 AM 2/6/2003, ando@sys-net.it wrote: >> >>>> Could we make the non-BAILOUT behaviour (add RDN attributes >>>> not specified in the entry) a configure- or run-time option? >>>> >>>> Unfortunately we must deal with some clients, such as Active >>>> Directory, that do not always include the RDN attribute in >>>> the entry. >>> >>>Personally, I don't like it; however, it is currently >>>a compile option: #undef BAILOUT in servers/slapd/add.c >>>and you get the desired behavior. It can be easily turned >> >> I have done that (#undef BAILOUT) for the moment. However we >> would prefer to use an unmodified OpenLDAP tree where possible... > >I'm in favour of having both behaviors in the main tree, with >a preference for the BAILOUT case > >> >>>into a config option, but I'd consider it confusing and >>>misleading. Maybe it could be part of the "schemacheck off" >>>option... >> >> How about an undocumented option? :-) > >I'd prefer documented options. Since I understand >there may be need for this "soft" case, and since this would >harmonize with the behavior of existing implementations, >I would not oppose a config option, with default to BAILOUT, >of course. > >Ando. > >-- >Pierangelo Masarati >mailto:pierangelo.masarati@sys-net.it
changed notes changed state Test to Release
changed notes changed state Release to Closed
moved from Software Bugs to Archive.Software Bugs
fixed in HEAD fixed in re21