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=00000000000002000007,ou=1,ou=Users,ou=132252,ou=Tenants,dc=CIDS" "cn=00000000000002000007" -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 00007f2ed4a60759 sp
00007f2e955e13e0 error 4 in libback-ldbm.so[7f2ed4a34000+8f000]
#0 0x00007f2ed4a60759 in id2entry_add_ext () from
/usr/lib64/dirsrv/plugins/libback-ldbm.so
#1 0x00007f2ed4a8a34c in modify_update_all () from
/usr/lib64/dirsrv/plugins/libback-ldbm.so
#2 0x00007f2ed4a8eb4f in ldbm_back_modrdn () from
/usr/lib64/dirsrv/plugins/libback-ldbm.so
#3 0x00007f2eddbecdaa in ?? () from /usr/lib64/dirsrv/libslapd.so.0
#4 0x00007f2eddbed66c in do_modrdn () from
/usr/lib64/dirsrv/libslapd.so.0
#5 0x0000000000413904 in ?? ()
#6 0x00007f2edc0369e3 in ?? () from /lib64/libnspr4.so
#7 0x00007f2edb9d9851 in start_thread () from /lib64/libpthread.so.0
#8 0x00007f2edb72711d 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@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
