#5 LDAP search with base DN may return results outside the give

[Daniel Lutz]

I have setup serveral namespaces in my MyVirtualDirectory (0.8.3) configuration:
- ou=specialUsers, dc=test
- ou=company1, ou=users, dc=test
- ou=company2, ou=users, dc=test
- ou=groups, dc=test

These namespaces are populated with LDAPInterceptor chains:

Local DN: ou=specialUsers, dc=test
Remote DN: ou=specialUsers, dc=company1, dc=com

Local DN: ou=company1, ou=users, dc=test
Remote DN: ou=users, dc=company1, dc=com

Local DN: ou=company2, ou=users, dc=test
Remote DN: ou=users, dc=company2, dc=com

Local DN: ou=groups, dc=test
Remote DN: ou=groups, dc=company1, dc=com

I have noticed that if I do a search with base DN "ou=foo, ou=users, dc=test", I still get
the results from the namespaces "ou=company1, ou=users, dc=test" and "ou=company2, ou=users, dc=test".
Instead, I would expect to get no results, since the base DN "ou=foo, ou=users, dc=test" is out of scope.

It seems to me that MyVirtualDirectory goes down to "ou=users, dc=test", calls the LDAPInterceptor chains
for "ou=company1, ou=users, dc=test" and "ou=company2, ou=users, dc=test" and then doesn't check the results
against the given base "ou=foo, ou=users, dc=test".

I have setup MyVirtualDirectory with the following configuration (only important parts shown):

[...]

server.nameSpaces=Root,specialUsers,company1,company2,groups

#Define RootDSE
server.Root.chain=RootDSE
server.Root.nameSpace=
server.Root.weight=0

server.Root.RootDSE.className=net.sourceforge.myvd.inserts.RootDSE
server.Root.RootDSE.config.namingContexts=dc=test

# Namespace specialUsers
server.specialUsers.chain=specialUsers
server.specialUsers.nameSpace=ou=specialUsers,dc=test
server.specialUsers.weight=100

# Chain specialUsers
server.specialUsers.specialUsers.className=net.sourceforge.myvd.inserts.ldap.LDAPInterceptor
[...]
server.specialUsers.specialUsers.config.remoteBase=ou=specialUsers,dc=company1,dc=com
[...]

[...]

# Namespace company1
server.company1.chain=company1
server.company1.nameSpace=ou=company1,ou=users,dc=test
server.company1.weight=100

# Chain company1
server.company1.company1.className=net.sourceforge.myvd.inserts.ldap.LDAPInterceptor
[...]
server.company1.company1.config.remoteBase=ou=users,dc=company1,dc=com
[...]

[...]

# Namespace company2
server.company2.chain=company2
server.company2.nameSpace=ou=company2,ou=users,dc=test
server.company2.weight=100

# Chain company2
server.company2.company2.className=net.sourceforge.myvd.inserts.ldap.LDAPInterceptor
[...]
server.company2.company2.config.remoteBase=ou=users,dc=company2,dc=com
[...]

[...]

# Namespace groups
server.groups.chain=groups
server.groups.nameSpace=ou=groups,dc=test
server.groups.weight=100

# Chain groups
server.groups.groups.className=net.sourceforge.myvd.inserts.ldap.LDAPInterceptor
server.groups.groups.config.remoteBase=ou=groups,dc=company1,dc=com
[...]

[Daniel Lutz]

The problem might be in Router.search(...), where getLocalLevels(chain,base) is called.
getLocalLevels() calls getLevel(base.getDN()), which in turn searches for a Level matching
the base DN or a parent of it.

As I have seen, each namespace registers its backends using addBackend(...), where the backends are
put into "subtree" for the namespace's DN and all parent DN's.

I think if the base is explicitly given, as it's the case in Router.search(...), getLevel(...) should not try to find backends for
some parent DNs.

Thanks for having a closer look at it.