directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: [SchemaService]
Date Fri, 19 Jan 2007 23:16:59 GMT
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 

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.


View raw message