openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Re: (ITS#9001) try_read1msg() takes O(n) steps to lookup a matching request
by ondra＠mistotebe.net 29 Mar '19

29 Mar '19

On Fri, Mar 29, 2019 at 01:38:30PM +0000, ondra(a)openldap.org wrote: > Full_Name: Ondrej Kuznik > Version: re24/master > OS: > URL: https://github.com/mistotebe/openldap/tree/its9001 > Submission from: (NULL) (82.10.24.68) > > > If a client has thousands or more requests in flight at the same time, it has to > look up the right request every time it receives a response. As the requests are > tracked in a doubly-linked list, lookup tends to take O(n) steps whichever > direction we take and things generally get out of hand from there on. > > The linked branch puts them into a TAvl for quicker lookup, with another commit > to let people test as (t)avl code is part of liblutil at the moment. A trivial program to expose this behaviour is available at ftp://ftp.openldap.org/incoming/searcher.c The same program takes under a second to handle 100000 searches for cn=monitor and children when linked to the patched libldap. -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

(ITS#9001) try_read1msg() takes O(n) steps to lookup a matching request
by ondra＠openldap.org 29 Mar '19

29 Mar '19

Full_Name: Ondrej Kuznik Version: re24/master OS: URL: https://github.com/mistotebe/openldap/tree/its9001 Submission from: (NULL) (82.10.24.68) If a client has thousands or more requests in flight at the same time, it has to look up the right request every time it receives a response. As the requests are tracked in a doubly-linked list, lookup tends to take O(n) steps whichever direction we take and things generally get out of hand from there on. The linked branch puts them into a TAvl for quicker lookup, with another commit to let people test as (t)avl code is part of liblutil at the moment.

1 0

Re: (ITS#8997) openldap-nssov/back ldap segfault
by matt＠pallissard.net 28 Mar '19

28 Mar '19

--mcr7yvikhm7jn4cn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Please try this patch. Right on. Ran some initial tests, so far so good. I'll bang on it for a few hours and follow up sometime in the late afternoon. Thanks a bunch! You guys rock! Matt Pallissard --mcr7yvikhm7jn4cn Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQTvIUMPApUGn6YFkXl1uof+t048SQUCXJzldgAKCRB1uof+t048 SaMGAP9G5n22WPLEVK/7TJ3lSGjl+BNRaj5AC0U3Im+DE60JewD/TrMXYDYlwpu8 kdOwSqY3UvRKHMdI13cEg8MG6iH3yAo= =chSM -----END PGP SIGNATURE----- --mcr7yvikhm7jn4cn--

1 0

Re: (ITS#8997) openldap-nssov/back ldap segfault
by hyc＠symas.com 28 Mar '19

28 Mar '19

This is a multi-part message in MIME format. --------------23850F02105CA62A388BCB06 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Pallissard, Matthew wrote: >> Actually now that I'm looking more closely at this output; the last line below looks interesting. >> >> (I probably should have tacked this on the backtrace) >> >> Thread 4 "slapd" received signal SIGSEGV, Segmentation fault. >> [Switching to Thread 0x7ffff0c7c700 (LWP 341)] >> nssov_dn2uid (op=0x7ffff0c7b730, ni=0x555555a24420, dn=0x7fffe811eab0, uid=0x7fffe8002450) at passwd.c:137 >> 137 passwd.c: No such file or directory. >> > > Sorry, that was from the wrong output, see below for the correct snippet. > > Thread 3 "slapd" received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x7ffff277f700 (LWP 170)] > nssov_dn2uid (op=0x7ffff277e730, ni=0x555555a24420, dn=0x7fffe4128430, uid=0x7fffe4002430) at passwd.c:137 > 137 passwd.c: No such file or directory. > > Matt Pallissard > Thanks that was a crucial piece. Please try this patch. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --------------23850F02105CA62A388BCB06 Content-Type: text/plain; charset=UTF-8; name="dif.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dif.txt" diff --git a/servers/slapd/back-ldap/search.c b/servers/slapd/back-ldap/search.c index 63345aed22..82e72aa8a7 100644 --- a/servers/slapd/back-ldap/search.c +++ b/servers/slapd/back-ldap/search.c @@ -1006,6 +1006,7 @@ retry: e = ldap_first_entry( lc->lc_ld, result ); if ( e == NULL ) { /* the entry exists, but it doesn't match the filter? */ + rc = LDAP_NO_RESULTS_RETURNED; goto cleanup; } --------------23850F02105CA62A388BCB06--

1 0

Re: (ITS#8997) openldap-nssov/back ldap segfault
by matt＠pallissard.net 28 Mar '19

28 Mar '19

--mb3a5envygzqum4d Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Actually now that I'm looking more closely at this output; the last line below looks interesting. > > (I probably should have tacked this on the backtrace) > > Thread 4 "slapd" received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x7ffff0c7c700 (LWP 341)] > nssov_dn2uid (op=0x7ffff0c7b730, ni=0x555555a24420, dn=0x7fffe811eab0, uid=0x7fffe8002450) at passwd.c:137 > 137 passwd.c: No such file or directory. > Sorry, that was from the wrong output, see below for the correct snippet. Thread 3 "slapd" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ffff277f700 (LWP 170)] nssov_dn2uid (op=0x7ffff277e730, ni=0x555555a24420, dn=0x7fffe4128430, uid=0x7fffe4002430) at passwd.c:137 137 passwd.c: No such file or directory. Matt Pallissard --mb3a5envygzqum4d Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQTvIUMPApUGn6YFkXl1uof+t048SQUCXJzYtgAKCRB1uof+t048 ST8nAP9UWBuG0358vqbQnGRxp4y4YMol81iU7UJswPBjPaBzgwD9HNk+aOAJJ1rn Czboi8ftlPsM0xnB34jmHtIYLz6EWww= =Vmu0 -----END PGP SIGNATURE----- --mb3a5envygzqum4d--

1 0

Re: (ITS#8997) openldap-nssov/back ldap segfault
by matt＠pallissard.net 28 Mar '19

28 Mar '19

--vpit5odwafhd55ju Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2019-03-28T06:54:35, Pallissard, Matthew wrote: > On 2019-03-21T15:13:30, Pallissard, Matthew wrote: > > On 2019-03-20T22:01:40, Howard Chu wrote: > > > matt(a)pallissard.net wrote: > > > > > > > 2. Turning the log level to 0 /seems/ to make the issue go away. I'= ll report > > > > back once I can confirm that. >=20 > Follow up, turning the log level to 0 does *not* prevent these segfaults. >=20 > Matt Pallissard Actually now that I'm looking more closely at this output; the last line be= low looks interesting. (I probably should have tacked this on the backtrace) =20 Thread 4 "slapd" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ffff0c7c700 (LWP 341)] nssov_dn2uid (op=3D0x7ffff0c7b730, ni=3D0x555555a24420, dn=3D0x7fffe811eab0= , uid=3D0x7fffe8002450) at passwd.c:137 137 passwd.c: No such file or directory. Matt Pallissard --vpit5odwafhd55ju Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQTvIUMPApUGn6YFkXl1uof+t048SQUCXJzXNQAKCRB1uof+t048 SXioAQDKoJWdiIpuasjmkaDnSI/bPGhCdBEXuYQfyZV5pqe++AD9GvYTSddxicKP wD0noDfTRI7oS5heRZHOnYO/ZK83RQc= =djIS -----END PGP SIGNATURE----- --vpit5odwafhd55ju--

1 0

Re: (ITS#8997) openldap-nssov/back ldap segfault
by matt＠pallissard.net 28 Mar '19

28 Mar '19

--dtfibegrdp7hfoq4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On 2019-03-21T15:13:30, Pallissard, Matthew wrote: > On 2019-03-20T22:01:40, Howard Chu wrote: > > matt(a)pallissard.net wrote: > > > > > 2. Turning the log level to 0 /seems/ to make the issue go away. I'll report > > > back once I can confirm that. Follow up, turning the log level to 0 does *not* prevent these segfaults. Matt Pallissard --dtfibegrdp7hfoq4 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQTvIUMPApUGn6YFkXl1uof+t048SQUCXJzSGQAKCRB1uof+t048 SWYnAQDjIXjPORzGof/8TpqzansV7PXn5pdMnRxU14gqMcXsrwD+LS2nEqUmslpE T4PWgWNKb0AY0eWcSNAj+klqAkolcAs= =8ONg -----END PGP SIGNATURE----- --dtfibegrdp7hfoq4--

1 0

(ITS#9000) memberOf value is lost when group DN is modified with only case change
by clement.oudot＠worteks.com 27 Mar '19

27 Mar '19

Full_Name: Clement OUDOT Version: 2.4.47 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.250.130.213) We use a very standard configuration with memberof overlay. The issue is very easy to reproduce : * Create a group with a user in an OpenLDAP server using memberof overlay * The user should now have the group DN in memberOf attribute * Rename the group to change its case, for example uppercase the first letter * The group has be renamed but was removed form user memberOf attribute The OpenLDAP log is the following: 5c9ba447 conn=1000 op=23 MODRDN dn="cn=memberoftest,ou=groups,dc=example,dc=com" 5c9ba447 conn=1000 op=23: memberof_value_modify DN="uid=coudot,ou=users,dc=example,dc=com" add memberOf="cn=memberofTEST,ou=groups,dc=example,dc=com" failed err=20 Seems it is because memberof try to add the new value before deleting the old one. As the values are the same when ignoring the case, the modification is rejected. I would say that doing the LDAP_SLIST_REMOVE before the LDAP_SLIST_INSERT_HEAD in memberof.c should be enough but I don't know if this is safe.

1 0

Re: (ITS#8999) telephoneNumberMatch crashed slapd
by hyc＠symas.com 26 Mar '19

26 Mar '19

thomassiegmund(a)gmx.de wrote: > Full_Name: Thomas Siegmund > Version: 2.4.47 > OS: OpenBSD > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2a02:8106:22a:4b02:e76f:90a1:5b27:161e) > > > When importing/saving the following certificate as a userCertificate;binary, > slapd crashes when calling dnX509Normalize. > > Files: > telephoneNumberMatch.der > telephoneNumberMatch.ldif > telephoneNumberMatch.llog > > Thanks for the report. Fixed now in git master. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#8999) telephoneNumberMatch crashed slapd
by thomassiegmund＠gmx.de 26 Mar '19

26 Mar '19

Full_Name: Thomas Siegmund Version: 2.4.47 OS: OpenBSD URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2a02:8106:22a:4b02:e76f:90a1:5b27:161e) When importing/saving the following certificate as a userCertificate;binary, slapd crashes when calling dnX509Normalize. Files: telephoneNumberMatch.der telephoneNumberMatch.ldif telephoneNumberMatch.llog

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs