#48133 Non tombstone entry which dn starting with "nsuniqueid=...," cannot be deleted
Closed None Opened 4 years ago by nhosoi.

The fix does not or no longer work.

The tombstone dn is the same as the entrydn and when trying to add it to the cache it fails


An example entry that should be allowed to delete.
example.ldif

To test, 389-ds-base needs to be rebuilt with -DUNIQID_DEBUG.
{{{
$ diff -twU4 add.c add.c.uniqiddebug
--- add.c 2015-03-13 16:31:16.460261575 -0700
+++ add.c.uniqiddebug 2015-03-13 16:31:19.328224185 -0700
@@ -915,9 +915,13 @@
{
int i, rc = 0;
Slapi_RDN rdn = NULL;
char
value = NULL;
- char type[] = {SLAPI_ATTR_UNIQUEID, "modifytimestamp", "modifiersname", "internalmodifytimestamp",
+ char
type[] = {
+#if !defined(UNIQID_DEBUG)
+ SLAPI_ATTR_UNIQUEID,
+#endif
+ "modifytimestamp", "modifiersname", "internalmodifytimestamp",
"internalmodifiersname", "createtimestamp", "creatorsname", 0};

 if ((rdn = slapi_rdn_new())) {
     slapi_rdn_init_dn(rdn, slapi_entry_get_dn_const(e));

}}}
Add a test entry having a DN starting with nsuniqueid and no nsTombstone objectclass:
{{{
dn: nsuniqueid=1f67ee81-d2fd11e2-86b7d507-9f846621,uid=tuser0,ou=People,dc=example,dc=com
objectClass: extensibleObject
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
cn: test user0
sn: tuser1
uid: tuser0
givenName: tuser1
mail: tuser0@example.com
}}}
Then delele it:
{{{
$ ldapdelete -x -h localhost -p 389 -D 'cn=directory manager' -W
nsuniqueid=1f67ee81-d2fd11e2-86b7d507-9f846621,uid=TUser0,ou=People,dc=example,dc=com
}}}
Verify the entry is deleted/turned to be a real tombstone entry.
{{{
$ ldapsearch -LLLx -h localhost -p 389 -D 'cn=directory manager' -W -b "ou=People,dc=example,dc=com" "(objectclass=nstombstone)" objectclass
dn: nsuniqueid=fc86d526-c9d111e4-8463a248-b11b6a2b,nsuniqueid=1f67ee81-d2fd11e2-86b7d507-9f846621,uid=TUser0,ou=People,dc=example,dc=com
...
objectclass: nsTombstone
}}}
The tombstone entry will be the target of the tombstone reap.

Reviewed by Rich (Thank you!!)

Pushed to master:
3c3fe1b..f14fb8b master -> master
commit f14fb8b

Pushed to 389-ds-base-1.3.3:
775997f..ff224e7 389-ds-base-1.3.3 -> 389-ds-base-1.3.3
commit ff224e7

Pushed to 389-ds-base-1.3.2:
0e31f70..fac457e 389-ds-base-1.3.2 -> 389-ds-base-1.3.2
commit fac457e

Pushed to 389-ds-base-1.2.11:
accb863..3579393 389-ds-base-1.2.11 -> 389-ds-base-1.2.11
commit 3579393

The fix does not or no longer work. It reuses the entry dn as tombstone dn and if it attempts to add it to the cache it fails (because it is already there)

My test is:

create a normal tombstone
db2ldif -r
edit ldif and remove oc tombstone and parentuniqueid from the entry
ldif2db

{{{
ldapsearch -LLL -o ldif-wrap=no -h localhost -p 30522 -x -D "cn=directory manager" -w secret123 -b "ou=people,dc=example,dc=com" dn
dn: ou=People,dc=example,dc=com

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

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

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

dn: nsuniqueid=12432802-920d11e6-ab8d8005-8430f734,ou=People,dc=example,dc=com

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

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

$ ldapmodify -h localhost -p 30522 -x -D "cn=directory manager" -w secret123
dn: nsuniqueid=12432802-920d11e6-ab8d8005-8430f734,ou=People,dc=example,dc=com
changetype: delete

deleting entry "nsuniqueid=12432802-920d11e6-ab8d8005-8430f734,ou=People,dc=example,dc=com"

ldap_delete: Operations error (1)
}}}

but modrdn/delete works

A quick question... Is the behaviour in common with the tombstone leap? Is it failing now!?

Replying to [comment:9 nhosoi]:

A quick question... Is the behaviour in common with the tombstone leap? Is it failing now!?

Oops. Sorry... ^leap^reap^. :p

Question. Is it possible that the dn of the entry already has a nsuniqueid rdn attribute? Your fix removes the check to see if it does, so if the entry rdn already has nsuniqueid, it will get added again?

For example:

nsnuiqueid=72374738478478,uid=mark,nsuniqueid=72374738478478,uid=mark,dc=example,dc=com

Replying to [comment:13 mreynolds]:

Question. Is it possible that the dn of the entry already has a nsuniqueid rdn attribute? Your fix removes the check to see if it does, so if the entry rdn already has nsuniqueid, it will get added again?

For example:

nsnuiqueid=72374738478478,uid=mark,nsuniqueid=72374738478478,uid=mark,dc=example,dc=com

yes. We want to delete an entry with

{{{
dn: nsuniqueid=72374738478478,uid=mark,dc=example,dc=com
}}}
which is NOT a tombstone entry. I don't know how this entyr could be created, but if it exists, it as a normal entry and the deletion should follow the normal process, no special handling of dns. If we do not change the dn of the entry when turning it into the tombstone we fail to add it to the cache. With th eproposed fix the tombstone would be:

{{{
dn: nsuniqueid=72374738478478,nsuniqueid=72374738478478, uid=mark,dc=example,dc=com
}}}

It can be deleted, it is transformed into a tombstone and it is purged in tombstone reaping

Thanks for clarifying my concerns, ack.

committed to master

commit d1cb699

and 1.3.5

commit f5f2472

Metadata Update from @nhosoi:
- Issue set to the milestone: 1.3.4 backlog

2 years ago

Adding a test in lib389.

0001-Add-tests-for-ticket48133.patch

Metadata Update from @sramling:
- Issue close_status updated to: None (was: Fixed)

2 years ago

Metadata Update from @sramling:
- Custom field reviewstatus adjusted to review (was: ack)

2 years ago

The test case looks very good, thanks!
One thing that is good to test also, it is to make search to make sure that entry was really deleted.

Also, I am on PTO next few days, so other team members can feel free to 'ack' the change and push it.

Login to comment on this ticket.

Metadata
Attachments 1