Currently I'm trying to reproduce this in the test environment, but it
will take some time. Are you getting the same error using regular user
account (with sufficient rights to move an object) and directory
manager?
On Wed, 2012-11-14 at 16:56 +0100, Ludwig Krispenz wrote:
On 11/14/2012 04:39 PM, Vladimir Elisseev wrote:
We've done some more tests, and it appears that we can reproduce this
segfault only while using a particular LDAP account, but if we use
directory manager to perform the same change using ldapmodrdn,
everything works as expected (no segfault, but error). I think this is a
result of bad ACI's. I'm going to check what is wrong there. However, I
think that too restrictive ACI shouldn't lead to segfault anyway.
Vlad.
Yes, I did a test and get an err=32, which is correct. And you're right,
the server shouldn't crash. Could you try to provide a reproducable test
setup.
Regards,
Ludwig
On Wed, 2012-11-14 at 07:09 -0700, Rich Megginson wrote:
On 11/14/2012 02:05 AM, Vladimir Elisseev wrote:
Obviously, I've tried ldapmodify and, as expected, it ends with an
error, no segfaults. However, I just tried
ldapmodrdn -r -h localhost -p 389 -D cn=xxx -W
cn=0207,ou=1,ou=Users,ou=132252,ou=Tenants,dc=CIDS
cn=0207 -s
ou=DeletedUsers,ou=132245,ou=Tenants,DC=CIDS
where the target superior entry doesn't exist, and, to my surprise, this
leads to the same segfault... I don't think it's normal, isn't it?
BTW, we've opened a case at Red Hat (we have RHDS subscription)
regarding this issue, so I suppose we have top stop discussing this
problem here, right?
No, we do not have to stop discussing this problem here, but the Red Hat
support team should be aware of this email thread so that they can
follow it.
Regards,
Vladimir.
On Tue, 2012-11-13 at 09:58 -0800, Noriko Hosoi wrote:
(2012/11/13 05:22), Rich Megginson wrote:
On 11/13/2012 03:30 AM, Vladimir Elisseev wrote:
Hello,
First of all I'd say that most likely this segfault is a result of
badly designed application and/or bad coding. The segfault occurs while
this application tries to move an entry to non-existing LDAP container.
Unfortunately I don't have access to the source code of this app. The
segfault is below with backtrace from dgb:
ns-slapd[4983]: segfault at 18 ip 7f2ed4a60759 sp
7f2e955e13e0 error 4 in libback-ldbm.so[7f2ed4a34000+8f000]
#0 0x7f2ed4a60759 in id2entry_add_ext () from
/usr/lib64/dirsrv/plugins/libback-ldbm.so
#1 0x7f2ed4a8a34c in modify_update_all () from
/usr/lib64/dirsrv/plugins/libback-ldbm.so
#2 0x7f2ed4a8eb4f in ldbm_back_modrdn () from
/usr/lib64/dirsrv/plugins/libback-ldbm.so
#3 0x7f2eddbecdaa in ?? () from /usr/lib64/dirsrv/libslapd.so.0
#4 0x7f2eddbed66c in do_modrdn () from
/usr/lib64/dirsrv/libslapd.so.0
#5 0x00413904 in ?? ()
#6 0x7f2edc0369e3 in ?? () from /lib64/libnspr4.so
#7 0x7f2edb9d9851 in start_thread () from /lib64/libpthread.so.0
#8 0x7f2edb72711d in clone () from /lib64/libc.so.6
I'd appreciate any thoughts regarding what kind of (bad) things this
application is doing. Is it possible to have a kind of protection in
this case on directory server?
rpm -q 389-ds-base
Can you provide a full stack trace based on the instructions at
http://port389.org/wiki/FAQ#Debugging_Crashes ?
Also, can we have the modrdn operation you executed? Command line
history and/or the snippet of the access log would be helpful.
I tried these modrdns, but it failed with the expected errors... And the
server is up and running after that.
$ ldapmodify ...
dn: cn=HR,ou=Groups,dc=example,dc=com
changetype: modrdn
newrdn: cn=HR
deleteoldrdn: 1
newsuperior: ou=bogus,dc=example,dc=com
modifying rdn of entry cn=HR,ou=Groups,dc=example,dc=com
ldap_rename: No such object (32)
matched DN: dc=example,dc=com
$ ldapmodify ...
dn: cn=HR,ou=Groups,dc=example,dc=com
changetype: modrdn
newrdn: cn=HR
deleteoldrdn: 1
newsuperior: o=bogus.com
modifying rdn of entry cn=HR,ou=Groups,dc=example,dc=com
ldap_rename: Operation affects multiple DSAs (71)
additional info: Cannot move entries across backends
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
