directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu (JIRA)" <>
Subject [jira] Updated: (DIREVE-274) Adding a group with invalid member DN corrupts the server
Date Sun, 16 Oct 2005 04:49:48 GMT
     [ ]

Alex Karasulu updated DIREVE-274:

    Priority: Blocker  (was: Major)

Real serious problem.  However the fix is easy.  Looks like the group cache bombs on restart
because of a bad group member.  Really the DnParser is choking on a bad attribute that is
not recognized.  We just need to not freak out as bad as we do - catch the exception and warn
on the log about a bad group member.  This solves the serious problem.

The first problem worries me more actually.  It's probably caused by the same thing: the satisfaction
attribute is not recognized when the entry is being added to the cache.  This is done after
the entry is added to the partition.  We should not be freaking out like this if there is
bad data for uniqueMember or member attributes.  

The problem with our approach is that we are parsing the member value with a normalizing parser.
 Attempts to access the OID registry for attributes in a name that do not exist are raising
an exception.  Perhaps normalizing parsers should leave unrocognized attributes as-is.  This
would only partially fix this problem.  We still need to protect group cache management operations
from bad values in member attributes.

> Adding a group with invalid member DN corrupts the server
> ---------------------------------------------------------
>          Key: DIREVE-274
>          URL:
>      Project: Directory Server
>         Type: Bug
>     Reporter: Stefan Zoerner
>     Assignee: Alex Karasulu
>     Priority: Blocker
>      Fix For: 0.9.3

> If you add an entry like this to the server
> dn: cn=myGroup,dc=apache,dc=org
> cn: myGroup
> objectclass: top
> objectclass: groupOfUniqueNames
> uniqueMember: satisfaction=guaranteed
> e.g. with this command
> $ ldapadd -D uid=admin,ou=system -w ***** -h magritte -p 10389 -f addEntry.ldif
> the clients gets an error:
> ldap_add: Loop detected
> ldap_add: additional info: failed to add entry cn=myGroup,dc=apache,dc=org:
> javax.naming.NamingException: OID for name 'satisfaction' was not found within the OID
> stack trace omitted
> I am not sure whether this is correct behavior, other servers let me do that (i.e. add
a DN value with unknown attribute names). But this is another story.
> Problem 1: Actually, the entry is created:
> $ ldapsearch -h magritte -p 10389 -b dc=apache,dc=org -s one "(objectClass=*)"
> cn=myGroup,dc=apache,dc=org
> cn=myGroup
> objectclass=groupOfUniqueNames
> objectclass=top
> uniqueMember=satisfaction=guaranteed
> $
> Therefore, the error above does not tell the truth ("failed to add entry"). It is even
possible to delete this entry without any errors. And is is highly recommended to do this,
> Problem 2: (this is the major problem)
> After stopping the server, you can't restart it because of this illegal entry. Here is
the stacktrace.  
> Exception in thread "main" javax.naming.NamingException: OID for name 'satisfaction'
was not found within the OID registry
>         at org.apache.ldap.server.schema.GlobalOidRegistry.getOid(
>         at org.apache.ldap.server.schema.GlobalAttributeTypeRegistry.lookup(
>         at org.apache.ldap.server.schema.ConcreteNameComponentNormalizer.lookup(
>         at org.apache.ldap.server.schema.ConcreteNameComponentNormalizer.normalizeByName(
>         at
>         at
>         at
>         at
>         at
>         at
>         at org.apache.ldap.server.authz.GroupCache.addMembers(
>         at org.apache.ldap.server.authz.GroupCache.initialize(
>         at org.apache.ldap.server.authz.GroupCache.<init>(
>         at org.apache.ldap.server.authz.AuthorizationService.init(
>         at org.apache.ldap.server.interceptor.InterceptorChain.register0(
>         at org.apache.ldap.server.interceptor.InterceptorChain.register(
>         at org.apache.ldap.server.interceptor.InterceptorChain.init(
>         at org.apache.ldap.server.DefaultDirectoryService.initialize(
>         at org.apache.ldap.server.DefaultDirectoryService.startup(
>         at org.apache.ldap.server.jndi.AbstractContextFactory.getInitialContext(
>         at javax.naming.spi.NamingManager.getInitialContext(
>         at javax.naming.InitialContext.getDefaultInitCtx(
>         at javax.naming.InitialContext.init(
>         at javax.naming.InitialContext.<init>(
>         at<init>(
>         at org.apache.ldap.server.ServerMain.main(

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message