openldap-bugs April 2015

openldap-bugs@openldap.org

29 participants
104 discussions

(ITS#8112) man pages suggest using deprecated fuctions
by quanah＠openldap.org 22 Apr '15

22 Apr '15

Full_Name: Quanah Gibson-Mount Version: RE24 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.52.177) ldap_get_dn(3) states that when using the ldap_explode_rdn function, ldap_value_free can be used to free the results. However, ldap_value_free is deprecated. Making things worse, it is suggested that the replacement for ldap_value_free is ldap_value_free_len. ldap_value_free_len expects a bval array, whereas ldap_explode_rdn returns a char* array. Finally, if you look at the actual OpenLDAP library code, what is done there is: vv = ldap_explode_rdn( values[ n ], 0 ); LDAP_VFREE( vv ); where: #define LDAP_VFREE(v) (ber_memvfree_x((void **)(v),NULL)) so NEITHER ldap_value_free NOR ldap_value_free_len are even used when using the ldap_explode_rdn function.

1 0

Re: (ITS#8111) Re-ordering schema attributeTypes crashes slapd
by zach＠puppetlabs.com 22 Apr '15

22 Apr '15

I should have noted that this is in a mutli master replication setup where all databases are being replicated, including cn=3Dconfig. --=20 Zach Leslie :: Puppet Labs

1 0

Re: (ITS#8111) Re-ordering schema attributeTypes crashes slapd
by zach＠puppetlabs.com 22 Apr '15

22 Apr '15

Below is the attempted ldif modification. dn: cn={5}puppet,cn=schema,cn=config changetype: modify replace: olcAttributeTypes olcAttributeTypes: {1}( 1.3.6.1.4.1.34380.556 NAME ('github' 'githubUsername') DESC 'github' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatc h SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) olcAttributeTypes: {2}( 1.3.6.1.4.1.34380.558 NAME ('pronoun' 'preferredPronou n') DESC 'prefered gender pronoun' EQUALITY caseIgnoreMatch SUBSTR case IgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) olcAttributeTypes: {3}( 1.3.6.1.4.1.34380.560 NAME 'skills' DESC 'skills, lang uages, specialties' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsM atch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) olcAttributeTypes: {4}( 1.3.6.1.4.1.34380.562 NAME 'onCall' DESC 'whether they are oncall or not that week' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.14 66.115.121.1.7 ) olcAttributeTypes: {5}( 1.3.6.1.4.1.34380.563 NAME 'googleGroups' DESC 'email groups they are in' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsM atch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) olcAttributeTypes: {6}( 1.3.6.1.4.1.34380.566 NAME 'projects' DESC 'ownership of projects' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) olcAttributeTypes: {7}( 1.3.6.1.4.1.34380.569 NAME 'interestingFact' DESC 'int eresting fact from first all hands' EQUALITY caseIgnoreMatch SUBSTR caseI gnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) olcAttributeTypes: {8}( 1.3.6.1.4.1.34380.570 NAME ('twitterHandle' 'twitter') DESC 'twitter handle' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstrin gsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) olcAttributeTypes: {9}( 1.3.6.1.4.1.34380.571 NAME ('ircNickname' 'irc') DESC 'irc nickname' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) olcAttributeTypes: {10}( 1.3.6.1.4.1.34380.572 NAME 'shirtSize' DESC 'shirtsiz e' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3 .6.1.4.1.1466.115.121.1.15 ) olcAttributeTypes: {11}( 1.3.6.1.4.1.34380.573 NAME 'dietaryRestrictions' DE SC 'carnivore, omnivore, veg, vegan, glutenfree, soyfree, air free' EQUALIT Y caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.146 6.115.121.1.15 ) olcAttributeTypes: {12}( 1.3.6.1.4.1.34380.567 NAME 'steamAccount' DESC 'ste amaccount for games' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstrings Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) olcAttributeTypes: {13}( 1.3.6.1.4.1.34380.801 NAME 'bribeMeWith' DESC 'thin gs I like' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SY NTAX 1.3.6.1.4.1.1466.115.121.1.15 ) olcAttributeTypes: {14}( 1.3.6.1.4.1.34380.802 NAME 'languages' DESC 'what d o you speak' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) olcAttributeTypes: {15}( 1.3.6.1.4.1.34380.574 NAME 'x-kvm-access' DESC 'kvm access level' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) olcAttributeTypes: {2}( 1.3.6.1.4.1.34380.557 NAME ('forge' 'forgeUsername') DESC 'forge' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) - -- Zach Leslie :: Puppet Labs

1 0

(ITS#8111) Re-ordering schema attributeTypes crashes slapd
by zach＠puppetlabs.com 22 Apr '15

22 Apr '15

Full_Name: Zach Leslie Version: 2.4.40-1 OS: Debian Wheezy URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.69.65.15) I have a custom schema that contains a handful of attributeTypes and a few objectClasses. If I add a new attributeType to the existing schema, and then attempt to reorder that type, slapd crashes. Starting the service again, slapd seems to behave normally, and the schema looks intact as it did prior to the attempted order modification.

1 0

Re: (ITS#8008) proxyauth with saslmech EXTERNAL not working
by mathieu.baeumler＠gmail.com 22 Apr '15

22 Apr '15

Hello, just in case someone is still looking on this, I stumbled on the same issue when upgrading openldap from an old version (2.4.2x) to 2.4.40. Used first a debian package, then compiled it myself, same behaviour. However, I managed to make it work by setting explicitly the "override" flag in the chain-idassert-bind parameters ( I'm not sure it's the right way to fix this "issue"): chain-idassert-authzFrom "dn:*" chain-idassert-bind bindmethod=sasl saslmech="EXTERNAL" mode=self flags=override,proxy-authz-critical starttls=critical tls_cacert=/etc/ldap/ssl/CA.pem tls_key=/etc/ldap/ssl/private/key.pem tls_cert=/etc/ldap/ssl/proxy.pem tls_reqcert=demand For those who like the cn=config syntax better: olcDbIDAssertBind: mode=self flags=flags=prescriptive,override,proxy-authz-critical bindmethod=sasl timeout=0 network-timeout=0 saslmech=EXTERNAL keepalive=0:0:0 starttls=critical tls_cert="/opt/SNet/etc/ldap/ssl/proxy.pem" tls_key="/opt/SNet/etc/ldap/ssl/private/key.pem" tls_cacert="/opt/SNet/etc/ldap/ssl/CA.pem" tls_reqcert=demand Note: Previous to that, the flags were NOT set explicitly, so the following default values were used: olcDbIDAssertBind: mode=self flags=prescriptive,proxy-authz-non-critical bindmethod=sasl timeout=0 network-timeout=0 saslmech=EXTERNAL keepalive=0:0:0 starttls=critical tls_cert="/opt/SNet/etc/ldap/ssl/proxy.pem" tls_key="/opt/SNet/etc/ldap/ssl/private/key.pem" tls_cacert="/opt/SNet/etc/ldap/ssl/CA.pem" tls_reqcert=demand

1 0

Re: (ITS#8110) ldap_sasl_bind_s does not honor LDAP_OPT_NETWORK_TIMEOUT for TLS connections
by ahochhaus＠samegoal.com 21 Apr '15

21 Apr '15

On Tue, Apr 21, 2015 at 12:58 PM, Howard Chu <hyc(a)symas.com> wrote: > > ahochhaus(a)samegoal.com wrote: >> >> Full_Name: Andy >> Version: 2.4.30 >> OS: Debian Linux (Jessie) >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (67.188.115.159) >> >> >> Hello, >> >> When connecting over TLS to an LDAP server with high packet loss, my calls to >> ldap_sasl_bind_s() block forever some of the time despite have set a 10s limit >> on all of LDAP_OPT_NETWORK_TIMEOUT, LDAP_OPT_TIMEOUT and LDAP_OPT_TIMELIMIT. >> >> I see the following stack trace on the deadlocked process. >> >> @ 0x7f2ff0c0f8d0 (unknown) >> @ 0x7f2ff0c0eac0 __libc_read >> @ 0x5cdc68 sb_debug_read >> @ 0x5c26f5 tlso_bio_read >> @ 0x451b64 BIO_read >> @ 0x49bf86 ssl3_read_n >> @ 0x49d52b ssl3_get_record >> @ 0x49caea ssl3_read_bytes >> @ 0x496f61 ssl3_get_message >> @ 0x496944 ssl3_get_finished >> @ 0x5e4aab ssl3_connect >> @ 0x5e164b ssl23_connect >> @ 0x5c1b3c tlso_session_connect >> @ 0x5b6773 ldap_int_tls_start >> @ 0x5b3a77 ldap_int_open_connection >> @ 0x5a730e ldap_new_connection >> @ 0x5b3365 ldap_open_defconn >> @ 0x5a68e3 ldap_send_initial_request >> @ 0x5a4c1e ldap_sasl_bind >> @ 0x5a4d99 ldap_sasl_bind_s >> >> Inspecting the source, I see that SSL_connect() is called from >> tlso_session_connect(). Does openldap attempt to pass timeout information to >> openssl? >> >> Sorry for the vague bug report. The issue is non-deterministic so it is hard to >> provide too much information. Please let me know what I can do to be more >> helpful. >> >> I was able to find an old posting (from 2006) reporting a similar issue. I'm >> uncertain if the root cause is the same or not though. >> >> http://www.openldap.org/lists/openldap-software/200601/msg00440.html > > > There is no API for setting a timeout in the TLS library. > > http://www.openldap.org/lists/openldap-software/200707/msg00346.html Thanks for the pointer. Feel free to close this issue. -Andy

1 0

Re: (ITS#8110) ldap_sasl_bind_s does not honor LDAP_OPT_NETWORK_TIMEOUT for TLS connections
by hyc＠symas.com 21 Apr '15

21 Apr '15

ahochhaus(a)samegoal.com wrote: > Full_Name: Andy > Version: 2.4.30 > OS: Debian Linux (Jessie) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (67.188.115.159) > > > Hello, > > When connecting over TLS to an LDAP server with high packet loss, my calls to > ldap_sasl_bind_s() block forever some of the time despite have set a 10s limit > on all of LDAP_OPT_NETWORK_TIMEOUT, LDAP_OPT_TIMEOUT and LDAP_OPT_TIMELIMIT. > > I see the following stack trace on the deadlocked process. > > @ 0x7f2ff0c0f8d0 (unknown) > @ 0x7f2ff0c0eac0 __libc_read > @ 0x5cdc68 sb_debug_read > @ 0x5c26f5 tlso_bio_read > @ 0x451b64 BIO_read > @ 0x49bf86 ssl3_read_n > @ 0x49d52b ssl3_get_record > @ 0x49caea ssl3_read_bytes > @ 0x496f61 ssl3_get_message > @ 0x496944 ssl3_get_finished > @ 0x5e4aab ssl3_connect > @ 0x5e164b ssl23_connect > @ 0x5c1b3c tlso_session_connect > @ 0x5b6773 ldap_int_tls_start > @ 0x5b3a77 ldap_int_open_connection > @ 0x5a730e ldap_new_connection > @ 0x5b3365 ldap_open_defconn > @ 0x5a68e3 ldap_send_initial_request > @ 0x5a4c1e ldap_sasl_bind > @ 0x5a4d99 ldap_sasl_bind_s > > Inspecting the source, I see that SSL_connect() is called from > tlso_session_connect(). Does openldap attempt to pass timeout information to > openssl? > > Sorry for the vague bug report. The issue is non-deterministic so it is hard to > provide too much information. Please let me know what I can do to be more > helpful. > > I was able to find an old posting (from 2006) reporting a similar issue. I'm > uncertain if the root cause is the same or not though. > > http://www.openldap.org/lists/openldap-software/200601/msg00440.html There is no API for setting a timeout in the TLS library. http://www.openldap.org/lists/openldap-software/200707/msg00346.html -- -- 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#8110) ldap_sasl_bind_s does not honor LDAP_OPT_NETWORK_TIMEOUT for TLS connections
by ahochhaus＠samegoal.com 21 Apr '15

21 Apr '15

Full_Name: Andy Version: 2.4.30 OS: Debian Linux (Jessie) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (67.188.115.159) Hello, When connecting over TLS to an LDAP server with high packet loss, my calls to ldap_sasl_bind_s() block forever some of the time despite have set a 10s limit on all of LDAP_OPT_NETWORK_TIMEOUT, LDAP_OPT_TIMEOUT and LDAP_OPT_TIMELIMIT. I see the following stack trace on the deadlocked process. @ 0x7f2ff0c0f8d0 (unknown) @ 0x7f2ff0c0eac0 __libc_read @ 0x5cdc68 sb_debug_read @ 0x5c26f5 tlso_bio_read @ 0x451b64 BIO_read @ 0x49bf86 ssl3_read_n @ 0x49d52b ssl3_get_record @ 0x49caea ssl3_read_bytes @ 0x496f61 ssl3_get_message @ 0x496944 ssl3_get_finished @ 0x5e4aab ssl3_connect @ 0x5e164b ssl23_connect @ 0x5c1b3c tlso_session_connect @ 0x5b6773 ldap_int_tls_start @ 0x5b3a77 ldap_int_open_connection @ 0x5a730e ldap_new_connection @ 0x5b3365 ldap_open_defconn @ 0x5a68e3 ldap_send_initial_request @ 0x5a4c1e ldap_sasl_bind @ 0x5a4d99 ldap_sasl_bind_s Inspecting the source, I see that SSL_connect() is called from tlso_session_connect(). Does openldap attempt to pass timeout information to openssl? Sorry for the vague bug report. The issue is non-deterministic so it is hard to provide too much information. Please let me know what I can do to be more helpful. I was able to find an old posting (from 2006) reporting a similar issue. I'm uncertain if the root cause is the same or not though. http://www.openldap.org/lists/openldap-software/200601/msg00440.html Thanks, -Andy

1 0

Re: (ITS#7145) cn=Connection 0
by hguo＠suse.com 20 Apr '15

20 Apr '15

Good day Michael. I built the branch OPENLDAP_REL_ENG_2_4 revision d281bd3, unfortunately connection 0 still shows up twice. The source code of my test case is here: https://github.com/HouzuoGuo/ldap-conn0 Would you mind to try it out in your test environment? Thanks. Regards, Howard On 10/04/15 15:44, Michael Ströder wrote: > hguo(a)suse.com wrote: >> Is your build identical to the 2.4.40 on OBS in terms of patches/source >> code revision? > > No. It's RE24 with all changes to be released as 2.4.41. > >> What distribution did you use for testing? > > openSUSE Tumbleweed x86_64. > > Ciao, Michael. > .

1 0

Re: (ITS#8095) Patch
by rouzier＠gmail.com 19 Apr '15

19 Apr '15

--047d7bfcf1deec63470514165cd2 Content-Type: text/plain; charset=UTF-8 My Testing does show it is not worth it for the data size in the db. Also there is a race condition using sendfile on linux that could happen. It is avoidable but it would require changes to the protocol to avoid it which I am not willing to do. So dismiss my patch with extreme prejudice On Wed, Apr 15, 2015 at 10:37 PM, Howard Chu <hyc(a)symas.com> wrote: > rouzier(a)gmail.com wrote: > >> Full_Name: James Rouzier >> Version: >> OS: >> URL: ftp://ftp.openldap.org/incoming/james-rouzier-150331.patch >> Submission from: (NULL) (192.222.129.11) >> >> >> I am working on a proof of concept of a simple key value store service >> using >> lmdb as the back end. >> I am using sendfile to avoid an extra copy. >> I accomplished this by creating function to extract get the mmap ptr from >> the >> env so I can calculate the offset of data. >> > > I'm quite reluctant to return the mmap pointer. In a WRITEMAP environment > that invites all manner of undetectable/unpreventable corruptions. > > Have you actually measured the performance difference between using > sendfile() here and plain write() or send()? The kernel doesn't physically > copy the written data from user space to kernel space, it just maps in a > particular page. Since LMDB data is already mmap'd, the kernel has very > little work to do since the relevant pages are already present in the > kernel's page tables. > > Ultimately sending data over TCP involves byte-by-byte iteration anyway, > since TCP checksums must be computed on all outgoing data. Doesn't seem to > me like sendfile can be a very significant optimization here. > >> >> I figured that function might be useful to the bigger community. >> >> If it does not fit in the bigger vision of lmdb it is fine not to include >> it. >> >> >> I, James Rouzier, hereby place the following modifications to OpenLDAP >> Software >> (and only these modifications) into the public domain. Hence, these >> modifications may be freely used and/or redistributed for any purpose >> with or >> without attribution and/or other notice. >> >> >> >> > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > --047d7bfcf1deec63470514165cd2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">My Testing doe= s show it is not worth it for the data size in the db.<br><br><div>Also the= re is a race condition using sendfile on linux that could happen.<br>It is = avoidable but it would require changes to=C2=A0the protocol to avoid it whi= ch I am not willing to do.<br><br>So dismiss my patch with extreme prejudic= e<br><br><br></div></div><div><div><div class=3D"gmail_extra"><br><div clas= s=3D"gmail_quote">On Wed, Apr 15, 2015 at 10:37 PM, Howard Chu <span dir=3D= "ltr"><<a href=3D"mailto:hyc@symas.com" target=3D"_blank">hyc(a)symas.com<= /a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:= 0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><a href=3D"mailto:r= ouzier(a)gmail.com" target=3D"_blank">rouzier(a)gmail.com</a> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Full_Name: James Rouzier<br> Version:<br> OS:<br> URL: <a href=3D"ftp://ftp.openldap.org/incoming/james-rouzier-150331.patch"= target=3D"_blank">ftp://ftp.openldap.org/incoming/james-rouzier-150331.pat= ch</a><br> Submission from: (NULL) (192.222.129.11)<br> <br> <br> I am working on a proof of concept of a simple key value store service usin= g<br> lmdb as the back end.<br> I am using sendfile to avoid an extra copy.<br> I accomplished this by creating function to extract get the mmap ptr from t= he<br> env so I can calculate the offset of data.<br> </blockquote> <br> I'm quite reluctant to return the mmap pointer. In a WRITEMAP environme= nt that invites all manner of undetectable/unpreventable corruptions.<br> <br> Have you actually measured the performance difference between using sendfil= e() here and plain write() or send()? The kernel doesn't physically cop= y the written data from user space to kernel space, it just maps in a parti= cular page. Since LMDB data is already mmap'd, the kernel has very litt= le work to do since the relevant pages are already present in the kernel&#3= 9;s page tables.<br> <br> Ultimately sending data over TCP involves byte-by-byte iteration anyway, si= nce TCP checksums must be computed on all outgoing data. Doesn't seem t= o me like sendfile can be a very significant optimization here.<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> <br> I figured that function might be useful to the bigger community.<br> <br> If it does not fit in the bigger vision of lmdb it is fine not to include i= t.<br> <br> <br> I, James Rouzier, hereby place the following modifications to OpenLDAP Soft= ware<br> (and only these modifications) into the public domain. Hence, these<br> modifications may be freely used and/or redistributed for any purpose with = or<br> without attribution and/or other notice.<br> <br> <br> <br><span><font color=3D"#888888"> </font></span></blockquote><span><font color=3D"#888888"> <br> <br> -- <br> =C2=A0 -- Howard Chu<br> =C2=A0 CTO, Symas Corp.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"= http://www.symas.com" target=3D"_blank">http://www.symas.com</a><br> =C2=A0 Director, Highland Sun=C2=A0 =C2=A0 =C2=A0<a href=3D"http://highland= sun.com/hyc/" target=3D"_blank">http://highlandsun.com/hyc/</a><br> =C2=A0 Chief Architect, OpenLDAP=C2=A0 <a href=3D"http://www.openldap.org/p= roject/" target=3D"_blank">http://www.openldap.org/project/</a><br> </font></span></blockquote></div><br></div> </div></div></div><br></div> --047d7bfcf1deec63470514165cd2--

1 0

← Newer
1
2
3
4
5
6
7
8
...
11
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs April 2015