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?
Regards, Vlad.
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 ?
Regards, Vlad.
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
(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
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?
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
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@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
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.
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@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
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@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
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=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@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
On 11/14/2012 09:04 AM, Vladimir Elisseev wrote:
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?
https://fedorahosted.org/389/ticket/520
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=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@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
I wasn't able to reproduce this segfault using CentOS: Name : 389-ds-base Arch : x86_64 Version : 1.2.9.14 Release : 1.el6
However, when I updated to Name : 389-ds-base Arch : x86_64 Version : 1.2.10.2 Release : 20.el6_3
I've got the same segfault. I'll provide the full staketrace soon.
Regards, Vlad.
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@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
Here is the full stacktrace of this segfault: http://pastebin.com/ReqQU3mM
Regards, Vlad.
389-users@lists.fedoraproject.org
-
Ludwig Krispenz -
Noriko Hosoi -
Rich Megginson -
Vlad