#47396 crash on tombstone modrdn
Closed: Fixed None Opened 6 years ago by nkinder.

The behaviour of modrdn for a tombstone entry is very inconsistent. Modrdn has two options: deleteoldrdn and newsuperior and the result is different for different combinations:

deleteoldrdn: 1 NO newsuperior: ==> err=53 (unwilling to perform)
deleteoldrdn: 1 newsuperior: <dn> ==> err=53 (unwilling to perform)
deleteoldrdn: 0 NO newsuperior ==> err=1 (operations error)
deleteoldrdn: 0 newsuperior: <dn> ==> CRASH

The crash has the side effect, that the entry is no longer accessable after restart, an attempt to repeat the operation gives err=32 (no such object)

What's next:
1] Define the expected behaviour, consistent to all combinations. In my opinion tombstone entries are internal and direct modifications should be prevented, so err=53 seems appropriate.
2] Implement 1]
3] Investigate if there is a proper way to resurrect tombstones by a client


$ git merge bz974719
Updating c6a72a5..0c9e3b1
Fast-forward
ldap/servers/slapd/back-ldbm/ldbm_modify.c | 7 +++++++
ldap/servers/slapd/back-ldbm/ldbm_modrdn.c | 7 +++++++
2 files changed, 14 insertions(+)
$ git push origin master
Counting objects: 15, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (8/8), done.
Writing objects: 100% (8/8), 1.45 KiB, done.
Total 8 (delta 6), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
c6a72a5..0c9e3b1 master -> master

fix backported to 1.2.11, 1.3.0 and 1.3.1

Metadata Update from @lkrispen:
- Issue assigned to lkrispen
- Issue set to the milestone: 1.2.11.22

2 years ago

Login to comment on this ticket.

Metadata