[389-users] segfault while moving entry to non-existent LDAP container

Wed Nov 14 19:45:56 UTC 2012

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