Failed to delete entries under multiple backends

[yavis73]

Describe the bug
When multiple backends (Up-down dependent) are configured, some entries cannot be deleted.

To Reproduce
Steps to reproduce the behavior:
1. install opendj 4.4.2 or 4.4.3 (the default backend suffix is created by "dc=com")
--> 10 people entry

2. Create multiple back ends using the control panel or the dsconfig create-backend.

:\Solution\opendj_4.4.3\opendj\bat\dsconfig.bat "create-backend" "--backend-name" "EX" "--set" "base-dn:dc=example,dc=com" "--set" "enabled:true" "--type" "je" "--hostName" "dsm-jakc-pc" "--port" "4444" "--bindDN" "cn=Directory Manager" "--bindPassword" "******" "--trustAll" "--noPropertiesFile" "--no-prompt"

Creating backend 'EX' containing base DN 'dc=example,dc=com' ..... Done

--> 1 people entry

D:\Solution\opendj_4.4.3\opendj\bat\dsconfig.bat "create-backend" "--backend-name" "EX2" "--set" "base-dn:dc=example2,dc=com" "--set" "enabled:true" "--type" "je" "--hostName" "dsm-jakc-pc" "--port" "4444" "--bindDN" "cn=Directory Manager" "--bindPassword" "******" "--trustAll" "--noPropertiesFile" "--no-prompt"

Creating backend 'EX2' containing base DN 'dc=example2,dc=com' ..... Done

--> 1 people entry

3. entry serching by ldapserach

D:\Solution\opendj_4.4.3\opendj\bat>ldapsearch -D "cn=directory manager" -w dirmanager -b dc=com "objectclass=*" dc ou uid

dn: dc=com
dc: com

dn: ou=People,dc=com
ou: People

dn: uid=user.0,ou=People,dc=com
uid: user.0

dn: uid=user.1,ou=People,dc=com
uid: user.1

dn: uid=user.2,ou=People,dc=com
uid: user.2

dn: uid=user.3,ou=People,dc=com
uid: user.3

dn: uid=user.4,ou=People,dc=com
uid: user.4

dn: uid=user.5,ou=People,dc=com
uid: user.5

dn: uid=user.6,ou=People,dc=com
uid: user.6

dn: uid=user.7,ou=People,dc=com
uid: user.7

dn: uid=user.8,ou=People,dc=com
uid: user.8

dn: uid=user.9,ou=People,dc=com
uid: user.9

dn: dc=example,dc=com
dc: example

dn: ou=People,dc=example,dc=com
ou: People

dn: uid=user.0,ou=People,dc=example,dc=com
uid: user.0

dn: dc=example2,dc=com
dc: example2

dn: ou=People,dc=example2,dc=com
ou: People

dn: uid=user.0,ou=People,dc=example2,dc=com
uid: user.0

D:\Solution\opendj_4.4.3\opendj\bat>

4. Try deleting any entry by ldapdelet

**D: \ Solution \ opendj_4.4.3 \ opendj \ bat> ldapdelete -D "cn = directory manager" -w dirmanager uid = user.0, ou = People, dc = com
Processing DELETE request for uid = user.0, ou = People, dc = com
The LDAP delete request failed: 66 (Not Allowed on Non-Leaf)
Additional Information: On the backend that should contain the item uid = user.0, ou = People, dc = com
This entry cannot be removed because the base DN of dc = example, dc = com is in the child backend below the target DN.

---- acces log --

[24 / Sept / 2019: 20: 54: 22 +0900] DELETE REQ conn = 19 op = 1 msgID = 2 dn = "uid = user.0, ou = People, dc = com"
[24 / Sept / 2019: 20: 54: 22 +0900] DELETE RES conn = 19 op = 1 msgID = 2 result = 66 message = "Item uid = user.0, ou = People, dc = com ) You cannot remove this entry because the backend to be included has a base DN of dc = example, dc = com in the child backend below the target DN. " etime = 0**

****Expected behavior
< Bottommost backend entry deleted normally>

: \ Solution \ opendj_4.4.3 \ opendj \ bat> ldapdelete -D "cn = directory manager" -w dirmanager uid = user.0, ou = People, dc = example2, dc = com
Processing DELETE request for id = user.0, ou = People, dc = example2, dc = com
The DELETE operation for uid = user.0, ou = People, dc = example2, dc = com was successful.

---acces log

[24/9월/2019:20:54:05 +0900] DELETE REQ conn=18 op=1 msgID=2 dn="uid=user.0,ou=People,dc=example2,dc=com"
[24/9월/2019:20:54:05 +0900] DELETE RES conn=18 op=1 msgID=2 result=0 etime=20

**Desktop **

• OS: windows 7
• Browser : not use

Server

• OS: windows 7
• LDAP Version : OpenDJ 4.4.2 & 4.4.3
• JDK : java version "1.8.0_211"
  Java(TM) SE Runtime Environment (build 1.8.0_211-b12)
  Java HotSpot(TM) 64-Bit Server VM (build 25.211-b12, mixed mode)

[yavis73]

Is this how to solve the problem?
What is your opinion?

org.opends.server.workflowelement.localbackend.LocalBackendDeleteOperation.java
--> 273 line ~ 284 line : change to inactivation(delete)

  // The selected backend will have the responsibility of making sure that
  // the entry actually exists and does not have any children (or possibly
  // handling a subtree delete). But we will need to check if there are
  // any subordinate backends that should stop us from attempting the delete

BackendConfigManager backendConfigManager =
DirectoryServer.getInstance().getServerContext().getBackendConfigManager();
for (DN dn : backendConfigManager.findSubordinateLocalNamingContextsForEntry(entryDN))
{
setResultCodeAndMessageNoInfoDisclosure(entry,
ResultCode.NOT_ALLOWED_ON_NONLEAF, ERR_DELETE_HAS_SUB_BACKEND.get(entryDN, dn));
return;
}

[yavis73]

This feature seems to prevent deletion when a parent backend entry is deleted when there is no child entry but a child backend exists.
However, the parent backend entry is never deleted because it does not check the lower backend of the entry, but the lower backend of the backend to which the entry belongs.

[jdelker]

I just bumped into this problem also.
Is there any workaround to remove an entry in the parent backend until this problem has been fixed?

[yavis73]

I just bumped into this problem also. Is there any workaround to remove an entry in the parent backend until this problem has been fixed?

my solution.
I modified the source below and recompiled it.
I couldn't find any other workaround.

opendj-server-legacy/src/main/java/org/opends/server/workflowelement/localbackend/LocalBackendDeleteOperation.java
277 line ------------------------------------------------- --------------------------

  BackendConfigManager backendConfigManager =      DirectoryServer.getInstance().getServerContext().getBackendConfigManager();
      for (DN dn: backendConfigManager.findSubordinateLocalNamingContextsForEntry(entryDN))
      {
        setResultCodeAndMessageNoInfoDisclosure(entry,
            ResultCode.NOT_ALLOWED_ON_NONLEAF, ERR_DELETE_HAS_SUB_BACKEND.get(entryDN, dn));
        return;
      }

==================================================== =======

BackendConfigManager backendConfigManager = DirectoryServer.getInstance().getServerContext().getBackendConfigManager();
      for (DN dn: backendConfigManager.findSubordinateLocalNamingContextsForEntry(entryDN))
      {
      if (dn.isInScopeOf(entryDN, SearchScope.WHOLE_SUBTREE)) {
          setResultCodeAndMessageNoInfoDisclosure(entry,
                  ResultCode.NOT_ALLOWED_ON_NONLEAF, ERR_DELETE_HAS_SUB_BACKEND.get(entryDN, dn));
          return;
        }
      }

[vharseko]

thanks @yavis73

[jdelker]

I'm afraid we need to reopen this, as it is obviously still not fixed with 4.8.0.

My scenario:
userRoot backend on dc=example,dc=com
employee backend on ou=employees,dc=example,dc=com
customer backend on ou=customer,dc=example,dc=com

I've created a new subtree in ou=others,dc=example,dc=com which thus falls in the userRoot backend.
Entries created within that subtree can not be deleted.
An delete operation on the existing entry cn=_obsolete_, ou=others,dc=example,dc=com fails with this message in the accesslog:

[14/Oct/2024:16:16:58 +0200] CONNECT conn=32 from=10.10.2.31:48282 to=10.10.0.135:1389 protocol=LDAP
[14/Oct/2024:16:16:58 +0200] EXTENDED REQ conn=32 op=0 msgID=1 name="StartTLS" oid="1.3.6.1.4.1.1466.20037"
[14/Oct/2024:16:16:58 +0200] EXTENDED RES conn=32 op=0 msgID=1 name="StartTLS" oid="1.3.6.1.4.1.1466.20037" result=0 etime=1
[14/Oct/2024:16:16:59 +0200] BIND REQ conn=32 op=1 msgID=2 version=3 type=SIMPLE dn="cn=Directory Manager"
[14/Oct/2024:16:16:59 +0200] BIND RES conn=32 op=1 msgID=2 result=0 authDN="cn=Directory Manager,cn=Root DNs,cn=config" etime=1
[14/Oct/2024:16:16:59 +0200] DELETE REQ conn=32 op=2 msgID=3 dn="cn=_obsolete_,ou=others,dc=example,dc=com"
[14/Oct/2024:16:16:59 +0200] DELETE RES conn=32 op=2 msgID=3 result=-1 etime=0
[14/Oct/2024:16:16:59 +0200] DISCONNECT conn=32 reason="Client Disconnect"

Note the result=-1!
There are no other messages in errors log.

[vharseko]

@jdelker please create issue