openldap-bugs

openldap-bugs@openldap.org

1 participants
20966 discussions

Re: (ITS#8107) olcMemberOfDangling: error doesn't prevent adding nonexistent member to group
by ryan＠nardis.ca 22 Apr '15

22 Apr '15

On Sat, Apr 18, 2015 at 10:47:57PM +0000, ryan(a)nardis.ca wrote: >Adding a new group containing a nonexistent member, or or a nonexistent >member to an existing group, triggers the following AddressSanitizer >splat. No error when adding a valid member, or with memberof disabled. That part turned out to be my fault, actually: > #0 0xebdb1e in lutil_strncopy /home/ryan/pkg/openldap/openldap/libraries/liblutil/utils.c:317:2 > #1 0xd10adb in mdb_dn2id /home/ryan/pkg/openldap/openldap/servers/slapd/back-mdb/dn2id.c:360:9 The nonexistent entry I was trying to add was outside the db suffix. Therefore nrlen in mdb_dn2id was wrong (in my specific case, negative) and things got worse from there. Testing with a nonexistent entry under the correct suffix, there are no complaints from AddressSanitizer. The buggy behaviour is still present, however: the member value is added despite returning a 'constraint violation' result.

1 0

(ITS#8113) Missing man page information for ldap_str2dn
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) According to a code comment, ldap_explode_rdn is deprecated, and the replacement is ldap_str2dn However, there is no man page info for ldap_str2dn

1 0

Re: (ITS#8112) man pages suggest using deprecated fuctions
by quanah＠zimbra.com 22 Apr '15

22 Apr '15

--On Wednesday, April 22, 2015 11:33 PM +0000 quanah(a)openldap.org wrote: > 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. According to *some* of the code, ldap_explode_rdn is actually deprecated: ldap_explode_rdn LDAP_P(( /* deprecated, ldap_str2rdn */ However, it is not wrapped in an ifdef for deprecated, nor is it listed as such in the manpage. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(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

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