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 ?

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(a)lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users(a)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(a)lists.fedoraproject.org >>> https://admin.fedoraproject.org/mailman/listinfo/389-users >> -- >> 389 users mailing list >> 389-users(a)lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users(a)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(a)lists.fedoraproject.org >>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users >>>> -- >>>> 389 users mailing list >>>> 389-users(a)lists.fedoraproject.org >>>> https://admin.fedoraproject.org/mailman/listinfo/389-users >> -- >> 389 users mailing list >> 389-users(a)lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/389-users > -- > 389 users mailing list > 389-users(a)lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users