You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Emmanuel Lecharny <el...@gmail.com> on 2007/01/19 23:33:58 UTC
[SchemaService]
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. 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 ?
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 ?
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 ?
3) Reagrding use of JNDI API
In some place of the code ( mainly tests ), 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 how to create MUST attributes if needed. Consider a call where name is
'ou=apache, ou=system', we will have to add an objectclass, but which one ? 'ou' is used by applicationEntity <http://ldap.akbkhome.com/index.php/objectclass/applicationEntity.html>, applicationProcess, <http://ldap.akbkhome.com/index.php/objectclass/applicationProcess.html>device, <http://ldap.akbkhome.com/index.php/objectclass/device.html>
groupOfNames <http://ldap.akbkhome.com/index.php/objectclass/groupOfNames.html>, groupOfUniqueNames, <http://ldap.akbkhome.com/index.php/objectclass/groupOfUniqueNames.html> organizationalRole, <http://ldap.akbkhome.com/index.php/objectclass/organizationalRole.html> organizationalUnit, <http://ldap.akbkhome.com/index.php/objectclass/organizationalUnit.html> organizationalPerson <http://ldap.akbkhome.com/index.php/objectclass/organizationalPerson.html>
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.
Special cases are like collective attributes, extensibleObject objectclasses, operational attributes, top, are supposed to be handled correctly.
Any ideas, comments, insight ?
Thanks !
Emmanuel
Re: [SchemaService]
Posted by Ersin Er <er...@gmail.com>.
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 <el...@gmail.com> 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]
Posted by Emmanuel Lecharny <el...@gmail.com>.
Thanks very much Alex and Stefan for your comments and tests !
> <snip/>
>
>>> 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:
>> <snip/>
>> (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]
Posted by Alex Karasulu <ak...@apache.org>.
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
Re: [SchemaService]
Posted by Stefan Zoerner <st...@labeo.de>.
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]
Posted by Alex Karasulu <ak...@apache.org>.
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