Re: [SchemaService]
Hi, As handling methods of most of the situations have been addressed I want to discuss the algorithms for Collective Attributes handling. Case 1: Entry Addition Besides other controls; IF 'objectClass' list includes 'collectiveAttributeSubentry' Allow any (collective) attribute to be added with the entry ELSE Deny entry addition if it contains any collective attribute Collective attributes can be physically stored only in subentries of type collectiveAttributeSubentry. As a collective attributes is flagged to be collective in the schema definition of the attribute, it can be easily checked whether an attribute is collective or not using the isCollective() method in our API. Case 2: Entry Modification Besides other controls; IF the new state of the entry contains collectiveAttributeSubentry as an objectClass value Allow any collective attributes which were already present in the entry to remain as are and allow any new collective attributes being added. ELSE Do not allow any remaining collective attributes in the entry (which may be a collective attribute subentry formerly) and do not allow any collective attributes to be added via ADD or REPLACE mods. Although these lines are not so long, in the schema service these checks cost lots of code and attention to be payed. I had implemented the first case but was blocked for the second case. I will give them a second try soon. On 1/20/07, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote: Special cases are like collective attributes, extensibleObject objectclasses, operational attributes, top, are supposed to be handled correctly. Any ideas, comments, insight ? Thanks ! Emmanuel -- Ersin
Re: [SchemaService]
Thanks very much Alex and Stefan for your comments and tests ! 2) Regarding missing attributes 2-a) If we have a RDN with an attribute not declared as an attribute of the entry, its should be rejected, as stated by RFC 2251 ( 4.7. Add Operation : "... - 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,..." Q : Is that ok with you to reject such entries ? I tried to add the following entry via JNDI call dn: cn=Kate Bush,dc=example,dc=com objectclass: top objectclass: person sn: Bush (1) IBM Tivoli Directory Server 6.0 creates the entry, and adds the missing cn attribute. The entry looks like this after creation: (2) Sun Java System Directory Server 5.2 behaves the same. (3) OpenLDAP 2.3 as well. So at least these three servers do not reject such an entry. I understand your cite from the RFC differently. But should we behave other like major players (I assume Fedora and Red Hat behave like Sun does). With this last example though CN is allowed to be added by the schema I think because it is a MAY attribute in person. In this case ApacheDS will add the attribute I think. It should if I remember correctly. However we should get a naming violation if we try to add CN to an entry that does not support a USER_APPLICATION attributeType used in the RDN. Alex yeah, I agree : if the entry list of objectclasses (explicit or implied) allow such an attribute, then it should be added into the entry. Ok, great... I think I know what my week-end will be all about :) Emmanuel
Re: [SchemaService]
Hi Stefan, Doing this helps so much to see what the expected behavior is across servers. Good going and thanks! More comments below ... Stefan Zoerner wrote: Hi Emmanuel! I tried out the situations described by you with some LDAP servers I have here (just to compare, which option they have choosen). Emmanuel Lecharny wrote: This is what I was trying to fix. Now, here are my questions : 1) Regarding missing ObjectClasses 1-a) We can add some of the missing ObjectClasses, like 'top', 'person', 'organizationalPerson', because we have all the needed informations to rebuild the hierarchy starting from 'inetOrgPerson'. Q : Is it a good idea to do so, instead of simply rejecting the entry ? I tried to add the following entry via JNDI call dn: cn=Kate Bush,dc=example,dc=com objectclass: inetOrgPerson sn: Bush cn: Kate Bush (1) IBM Tivoli Directory Server 6.0 creates the entry, but it adds the missing object classes. The entry looks like this after creation: dn: dn: cn=Kate Bush,dc=example,dc=com objectclass: inetOrgPerson objectclass: top objectclass: organizationalPerson objectclass: person sn: Bush cn: Kate Bush (2) Sun Java System Directory Server 5.2 creates the entry as well, and it also adds the missing object classes. Entry looks like above after creation. (3) OpenLDAP 2.3 creates the entry, it does not add the missing object classes. Entry looks like this after creation: dn: cn=Kate Bush,dc=example,dc=com objectClass: inetOrgPerson sn: Bush cn: Kate Bush (This one is a little surprise ...). 2) Regarding missing attributes 2-a) If we have a RDN with an attribute not declared as an attribute of the entry, its should be rejected, as stated by RFC 2251 ( 4.7. Add Operation : "... - 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,..." Q : Is that ok with you to reject such entries ? I tried to add the following entry via JNDI call dn: cn=Kate Bush,dc=example,dc=com objectclass: top objectclass: person sn: Bush (1) IBM Tivoli Directory Server 6.0 creates the entry, and adds the missing cn attribute. The entry looks like this after creation: dn: cn=Kate Bush,dc=example,dc=com objectclass: top objectclass: person sn: Bush cn: Kate Bush (2) Sun Java System Directory Server 5.2 behaves the same. (3) OpenLDAP 2.3 as well. So at least these three servers do not reject such an entry. I understand your cite from the RFC differently. But should we behave other like major players (I assume Fedora and Red Hat behave like Sun does). With this last example though CN is allowed to be added by the schema I think because it is a MAY attribute in person. In this case ApacheDS will add the attribute I think. It should if I remember correctly. However we should get a naming violation if we try to add CN to an entry that does not support a USER_APPLICATION attributeType used in the RDN. Alex begin:vcard fn:Alex Karasulu n:Karasulu;Alex org:Apache Software Foundation;Apache Directory adr:;;1005 N. Marsh Wind Way;Ponte Vedra ;FL;32082;USA email;internet:[EMAIL PROTECTED] title:Member, V.P. tel;work:(904) 791-2766 tel;fax:(904) 808-4789 tel;home:(904) 808-4789 tel;cell:(904) 315-4901 note;quoted-printable:AIM: alexokarasulu=0D=0A= MSN: [EMAIL PROTECTED] Yahoo!: alexkarasulu=0D=0A= IRC: aok=0D=0A= PGP ID: 1024D/4E1370F8 BBCC E8D8 8756 2D51 C3D4 014A 3662 F96F 4E13 70F8=0D=0A= x-mozilla-html:FALSE url:http://people.apache.org/~akarasulu version:2.1 end:vcard
Re: [SchemaService]
Hi Emmanuel! I tried out the situations described by you with some LDAP servers I have here (just to compare, which option they have choosen). Emmanuel Lecharny wrote: This is what I was trying to fix. Now, here are my questions : 1) Regarding missing ObjectClasses 1-a) We can add some of the missing ObjectClasses, like 'top', 'person', 'organizationalPerson', because we have all the needed informations to rebuild the hierarchy starting from 'inetOrgPerson'. Q : Is it a good idea to do so, instead of simply rejecting the entry ? I tried to add the following entry via JNDI call dn: cn=Kate Bush,dc=example,dc=com objectclass: inetOrgPerson sn: Bush cn: Kate Bush (1) IBM Tivoli Directory Server 6.0 creates the entry, but it adds the missing object classes. The entry looks like this after creation: dn: dn: cn=Kate Bush,dc=example,dc=com objectclass: inetOrgPerson objectclass: top objectclass: organizationalPerson objectclass: person sn: Bush cn: Kate Bush (2) Sun Java System Directory Server 5.2 creates the entry as well, and it also adds the missing object classes. Entry looks like above after creation. (3) OpenLDAP 2.3 creates the entry, it does not add the missing object classes. Entry looks like this after creation: dn: cn=Kate Bush,dc=example,dc=com objectClass: inetOrgPerson sn: Bush cn: Kate Bush (This one is a little surprise ...). 2) Regarding missing attributes 2-a) If we have a RDN with an attribute not declared as an attribute of the entry, its should be rejected, as stated by RFC 2251 ( 4.7. Add Operation : "... - 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,..." Q : Is that ok with you to reject such entries ? I tried to add the following entry via JNDI call dn: cn=Kate Bush,dc=example,dc=com objectclass: top objectclass: person sn: Bush (1) IBM Tivoli Directory Server 6.0 creates the entry, and adds the missing cn attribute. The entry looks like this after creation: dn: cn=Kate Bush,dc=example,dc=com objectclass: top objectclass: person sn: Bush cn: Kate Bush (2) Sun Java System Directory Server 5.2 behaves the same. (3) OpenLDAP 2.3 as well. So at least these three servers do not reject such an entry. I understand your cite from the RFC differently. But should we behave other like major players (I assume Fedora and Red Hat behave like Sun does). Greetings from stormy Hamburg, Stefan
Re: [SchemaService]
Emmanuel Lecharny wrote: Hi guys, I have been working for the last 3 days on DIRSERVER-758, and while trying to fix it, I just felt like I have found something pretty ugly. I need your opinion on some points, and choices. Just to summarize, DIRSERVER-758 was about creating an entry with attributes not existing or not part of any objectclasses. For instance, here is one kind of entry which is problematic : dn: c=france, ou=system objectclass : inetOrgPerson sn: emmanuel This entry has four problems : 1) The 'c' attribute is not declared in the entry's attributes 2) The 'c' attribute is associated with the 'country' object class, which is not listed as an attribute for this entry 3) Some object classes are missing : 'top', 'person', 'organizationalPerson' and of course 'country' 4) Som attributs are missing : 'sn', 'cn', declared in objectclass 'person' Ok, so far, it seems that this entry is not correct. Yes this is bad you should reject any entry that is being added like this. It's a schema violation. Alas, we can inject it in the server :( This is what I was trying to fix. Now, here are my questions : 1) Regarding missing ObjectClasses 1-a) We can add some of the missing ObjectClasses, like 'top', 'person', 'organizationalPerson', because we have all the needed informations to rebuild the hierarchy starting from 'inetOrgPerson'. Q : Is it a good idea to do so, instead of simply rejecting the entry ? Yeah this is an acceptable situation since inetOrgPerson implies person anyway. Did not my doco discuss this? I already fixed this issue by replacing the missing ancestors but not top. Please do not add 'top' because you will bloat the objectClass index. Top is injected on the return of all entries if not already present. Top is always assumed. 2) Regarding missing attributes 2-a) If we have a RDN with an attribute not declared as an attribute of the entry, its should be rejected, as stated by RFC 2251 ( 4.7. Add Operation : "... Yes it should be rejected. - 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,..." Q : Is that ok with you to reject such entries ? Yes absolutely we should not allow the use of attributes that do not exist in the entry in the name of the entry. 2-b) If an attribute is added to the entry, but without the associated ObjectClass, then it should not be accepted, unless we have added the missing ObjectClass following 1-a above Q : wdyt ? Well in the 1-a case I think we're covered since inetOrgPerson is going to allow everything that person does plus additional things. But in short I'd answer yes. 3) Reagrding use of JNDI API In some place of the code ( mainly tests ), Yeah we shouold fix these in those tests. If non tests use it this is a serious problem. I don't think anything but tests use this. we use the Context.createSubcontext( name ) method. This lead to a serious problem, because we have no clue about which objectclass to use and no clue about Do not presume any objectClass to use here. This is just flawed. However I think JNDI states that for LDAP providers this is to create a javaContainer from the java schema. I'd have to look into this. Yeah I'd stay away from this stuff. ... Other cases are pretty obvious : - an entry with missing attributes (declared as MUST in the entry's ObjectClass) should be considered as an error - an RDN like test=acme should not be accepted, unless 'test' is declared as a valid attribute. You're giving too much thought to this one. Don't worry about it. We just need to strip this stuff out of tests and where java tests are concerned with java schema usage we have to figure out what JNDI expects to do. I think without an Attributes object in createSubcontext( name ) this javaContainer is the objectClass used. The server side JNDI provider should substitute for this automatically. Special cases are like collective attributes, extensibleObject objectclasses, operational attributes, top, are supposed to be handled correctly. Yep I agree. Alex begin:vcard fn:Alex Karasulu n:Karasulu;Alex org:Apache Software Foundation;Apache Directory adr:;;1005 N. Marsh Wind Way;Ponte Vedra ;FL;32082;USA email;internet:[EMAIL PROTECTED] title:Member, V.P. tel;work:(904) 791-2766 tel;fax:(904) 808-4789 tel;home:(904) 808-4789 tel;cell:(904) 315-4901 note;quoted-printable:AIM: alexokarasulu=0D=0A= MSN: [EMAIL PROTECTED] Yahoo!: alexkarasulu=0D=0A= IRC: aok=0D=0A= PGP ID: 1024D/4E1370F8 BBCC E8D8 8756 2D51 C3D4 014A 3662 F96F 4E13 70F8=0D=0A= x-mozilla-html:FALSE url:http://people.apache.org/~akarasulu version:2.1 end:vcard
