openldap-bugs May 2019

openldap-bugs@openldap.org

19 participants
51 discussions

(ITS#9024) [PATCH] Fix union semun undefined from FreeBSD 12 onward
by khng300＠gmail.com 17 May '19

17 May '19

Full_Name: Ka Ho Ng Version: mdb.master OS: FreeBSD 12.0-RELEASE URL: ftp://ftp.openldap.org/incoming/Ka-Ho-Ng-190517.patch Submission from: (NULL) (2001:470:fa95:1300::3) Starting from __FreeBSD_version 1200059 union semun definition was removed from userspace headers in order to comply with POSIX. In order to resurrect the defintion we need to define _WANT_SEMUN before including sys/sem.h for __FreeBSD_version >= 1200059. I tried to touch as small amount of code as possible here to avoid interfering with other platforms I do not use. By the way, please help close ITS#8986 as this version is a resend of the patch.

1 0

RE: (ITS#9023) crash using ppolicy chaining from slave to master
by quanah＠symas.com 17 May '19

17 May '19

--On Friday, May 17, 2019 4:09 PM +0000 "AYANIDES, JEAN-PHILIPPE" <jpayanides(a)prosodie.com> wrote: > > > Hello Quanah, > > I am not very familiar with gdb. Can you help me doing that? Start slapd on the server that's crashing Get the process ID of slapd gdb /path/to/slapd PID For example, if slapd is located in /usr/sbin, and the process ID is 1234: gdb /usr/sbin/slapd 1234 At the (gdb) prompt, enter the command "cont" to continue execution Run your operation that causes slapd to crash. This should drop you back to the (gdb) prompt. Then run the command: thr apply all bt full This will provide the full backtrace. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

RE: (ITS#9023) crash using ppolicy chaining from slave to master
by jpayanides＠prosodie.com 17 May '19

17 May '19

--_000_AM0PR0202MB355359CC89C5DBD53D8FAB09BA0B0AM0PR0202MB3553_ Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hello Quanah, I am not very familiar with gdb. Can you help me doing that? ________________________________ De : Quanah Gibson-Mount <quanah(a)symas.com> Envoy=E9 : vendredi 17 mai 2019 16:58:59 =C0 : AYANIDES, JEAN-PHILIPPE; openldap-its(a)OpenLDAP.org Objet : Re: (ITS#9023) crash using ppolicy chaining from slave to master --On Friday, May 17, 2019 3:50 PM +0000 jpayanides(a)prosodie.com wrote: > Full_Name: JPh Ayanides > Version: 2.4.47 > OS: Linux Debian > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.46.216.78) > > > Hello, I cannot succeed in making the following configuration to work. > Instead of that, openldap crashes. > > I have 2 openldap servers in master-slave: the slave is installed on a > machine named rada, and a master is installed on another machine named > simby. The ppolicy is activated on rada and simby, and I use chain and > updateref in order to sync failures in ppolicy coming from rada back to > simby. When I test that feature, with trying a bind with a wrong > password, openldap on the slave crashes. I failed in understanding why, > even with gdb. Ensure you have debugging symbols installed, and provide a full backtrace of all threads from gdb. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com> This message contains information that may be privileged or confidential an= d is the property of the Capgemini Group. It is intended only for the perso= n to whom it is addressed. If you are not the intended recipient, you are n= ot authorized to read, print, retain, copy, disseminate, distribute, or use= this message or any part thereof. If you receive this message in error, pl= ease notify the sender immediately and delete all copies of this message. --_000_AM0PR0202MB355359CC89C5DBD53D8FAB09BA0B0AM0PR0202MB3553_ Content-Type: text/html; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 1"> <style type=3D"text/css" style=3D"display:none;"></style> </head> <body dir=3D"ltr"> <div id=3D"divtagdefaultwrapper" style=3D"font-size:12pt;color:#000000;font= -family:Calibri,Helvetica,sans-serif;" dir=3D"ltr"> <p style=3D"margin-top:0;margin-bottom:0">Hello Quanah,</p> <p style=3D"margin-top:0;margin-bottom:0">I am not very familiar with gdb. = Can you help me doing that?<br> </p> <strong><span style=3D"font-family:"Arial","sans-serif"= ; color:#0098CC"></span></strong> <div id=3D"Signature"></div> </div> <hr style=3D"display:inline-block;width:98%" tabindex=3D"-1"> <div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" st= yle=3D"font-size:11pt" color=3D"#000000"><b>De :</b> Quanah Gibson-Mount &l= t;quanah(a)symas.com><br> <b>Envoy=E9 :</b> vendredi 17 mai 2019 16:58:59<br> <b>=C0 :</b> AYANIDES, JEAN-PHILIPPE; openldap-its(a)OpenLDAP.org<br> <b>Objet :</b> Re: (ITS#9023) crash using ppolicy chaining from slave to ma= ster</font> <div> </div> </div> <div class=3D"BodyFragment"><font size=3D"2"><span style=3D"font-size:11pt;= "> <div class=3D"PlainText">--On Friday, May 17, 2019 3:50 PM +0000 jpayan= ides(a)prosodie.com wrote:<br> <br> > Full_Name: JPh Ayanides<br> > Version: 2.4.47<br> > OS: Linux Debian<br> > URL: <a href=3D"ftp://ftp.openldap.org/incoming/">ftp://ftp.openldap.o= rg/incoming/</a><br> > Submission from: (NULL) (195.46.216.78)<br> ><br> ><br> > Hello, I cannot succeed in making the following configuration to work.= <br> > Instead of that, openldap crashes.<br> ><br> > I have 2 openldap servers in master-slave: the slave is installed on a= <br> > machine named rada, and a master is installed on another machine named= <br> > simby. The ppolicy is activated on rada and simby, and I use chain and= <br> > updateref in order to sync failures in ppolicy coming from rada back t= o<br> > simby. When I test that feature, with trying a bind with a wrong<br> > password,  openldap on the slave crashes. I failed in understandi= ng why,<br> > even with gdb.<br> <br> Ensure you have debugging symbols installed, and provide a full backtrace <= br> of all threads from gdb.<br> <br> --Quanah<br> <br> <br> --<br> <br> Quanah Gibson-Mount<br> Product Architect<br> Symas Corporation<br> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:<br> <<a href=3D"http://www.symas.com">http://www.symas.com</a>><br> <br> </div> </span></font></div> <span style=3D"font-size: 9px; line-height: 10px;">This message contains in= formation that may be privileged or confidential and is the property of the= Capgemini Group. It is intended only for the person to whom it is addresse= d. If you are not the intended recipient, you are not authorized to read, p= rint, retain, copy, disseminate, distribute, or use this message or any par= t thereof. If you receive this message in error, please notify the sender i= mmediately and delete all copies of this message.</span></body> </html> --_000_AM0PR0202MB355359CC89C5DBD53D8FAB09BA0B0AM0PR0202MB3553_--

1 0

Re: (ITS#9023) crash using ppolicy chaining from slave to master
by quanah＠symas.com 17 May '19

17 May '19

--On Friday, May 17, 2019 3:50 PM +0000 jpayanides(a)prosodie.com wrote: > Full_Name: JPh Ayanides > Version: 2.4.47 > OS: Linux Debian > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.46.216.78) > > > Hello, I cannot succeed in making the following configuration to work. > Instead of that, openldap crashes. > > I have 2 openldap servers in master-slave: the slave is installed on a > machine named rada, and a master is installed on another machine named > simby. The ppolicy is activated on rada and simby, and I use chain and > updateref in order to sync failures in ppolicy coming from rada back to > simby. When I test that feature, with trying a bind with a wrong > password, openldap on the slave crashes. I failed in understanding why, > even with gdb. Ensure you have debugging symbols installed, and provide a full backtrace of all threads from gdb. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#9023) crash using ppolicy chaining from slave to master
by jpayanides＠prosodie.com 17 May '19

17 May '19

Full_Name: JPh Ayanides Version: 2.4.47 OS: Linux Debian URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.46.216.78) Hello, I cannot succeed in making the following configuration to work. Instead of that, openldap crashes. I have 2 openldap servers in master-slave: the slave is installed on a machine named rada, and a master is installed on another machine named simby. The ppolicy is activated on rada and simby, and I use chain and updateref in order to sync failures in ppolicy coming from rada back to simby. When I test that feature, with trying a bind with a wrong password, openldap on the slave crashes. I failed in understanding why, even with gdb. Here is the configuration of rada: --------------------------- allow bind_v2 sizelimit size.hard=10000 sizelimit size.soft=500 # Schema and objectClass definitions include /appli/openldap/etc/openldap/schema/core.schema include /appli/openldap/etc/openldap/schema/cosine.schema include /appli/openldap/etc/openldap/schema/nis.schema include /appli/openldap/etc/openldap/schema/inetorgperson.schema include /appli/openldap/etc/openldap/schema/ppolicy.schema pidfile /appli/openldap-preprod/var/run/slapd.pid argsfile /appli/openldap-preprod/var/run/slapd.args loglevel -1 conn_max_pending 250 idletimeout 600 timelimit time.soft=60 timelimit time.hard=60 modulepath /appli/openldap/libexec/openldap moduleload back_bdb moduleload ppolicy moduleload back_ldap moduleload pw-sha2 password-hash {SSHA512} TLSVerifyClient never TLSCertificateKeyFile /appli/openldap-preprod/etc/private/auth.gdr.key TLSCertificateFile /appli/openldap-preprod/etc/certs/auth.gdr.crt TLSCACertificatePath /appli/openldap-preprod/etc/ca/ overlay chain chain-uri ldaps://simby.example:637 chain-idassert-bind bindmethod="simple" binddn="uid=mirrormode,dc=example" credentials="secret" mode="self" tls_reqcert=allow chain-tls none chain-return-error TRUE database bdb suffix "dc=example" rootdn "cn=admin,dc=example" rootpw {SSHA}XXXXXXXXXXXXXXXXXXXXXX dbconfig set_cachesize 0 128000000 0 dbconfig set_lk_max_objects 1500 dbconfig set_lk_max_locks 1500 dbconfig set_lk_max_lockers 1500 directory "/appli/openldap-preprod/var/openldap-data" index objectClass,entryCSN,entryUUID eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index uidNumber,gidNumber,loginShell eq,pres index uid,memberUid eq,pres,sub index nisMapName,nisMapEntry eq,pres,sub overlay ppolicy ppolicy_default "cn=pwdDefault,ou=policies,dc=example" ppolicy_hash_cleartext ppolicy_use_lockout ppolicy_forward_updates lastmod on syncrepl rid=002 provider=ldap://simby.example:390 binddn="uid=mirrormode,dc=example" credentials=secret bindmethod=simple searchbase="dc=example" schemachecking=off type=refreshAndPersist retry="60 +" tls_cacert="/appli/openldap-preprod/etc/ca/CADSI.pem" tls_reqcert=allow starttls=yes updateref ldaps://simby.example:637 access to attrs=userPassword by dn="cn=admin,dc=example" write by dn="cn=acadmin,dc=example" write by dn="uid=mirrormode,dc=example" read by dn="uid=rsasecureid,dc=example" auth by anonymous auth by dn="uid=test,ou=People,dc=example" none by * none access to attrs=shadowLastChange by dn="cn=admin,dc=example" write by dn="uid=mirrormode,dc=example" read by dn="uid=test,ou=People,dc=example" none by * read access to dn="uid=test,ou=People,dc=example" by dn="cn=admin,dc=example" write by * read database monitor access to * by * read ----------------------------- and here is the configuration file on the master: ---------------------------- allow bind_v2 sizelimit size.hard=10000 sizelimit size.soft=500 include /appli/openldap/etc/openldap/schema/core.schema include /appli/openldap/etc/openldap/schema/cosine.schema include /appli/openldap/etc/openldap/schema/nis.schema include /appli/openldap/etc/openldap/schema/inetorgperson.schema include /appli/openldap/etc/openldap/schema/ppolicy.schema pidfile /appli/openldap-preprod/var/run/slapd.pid argsfile /appli/openldap-preprod/var/run/slapd.args loglevel -1 modulepath /appli/openldap/libexec/openldap moduleload back_bdb moduleload syncprov moduleload ppolicy moduleload pw-sha2 password-hash {SSHA512} TLSCertificateKeyFile /appli/openldap-preprod/etc/private/simby.example.key TLSCertificateFile /appli/openldap-preprod/etc/certs/simby.example.pem TLSCACertificatePath /appli/openldap-preprod/etc/ca TLSverifyClient never database bdb suffix "dc=example" rootdn "cn=admin,dc=example" rootpw {SSHA}XXXXXXXXXXXXXXXXXXX directory "/appli/openldap-preprod/var/openldap-data" index objectclass,entryCSN,entryUUID eq index ou,cn,mail,surname,givenname eq,pres,sub index uidNumber,gidNumber,loginShell eq,pres index uid,memberUid eq,pres,sub index nisMapName,nisMapEntry eq,pres,sub overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 overlay ppolicy ppolicy_default "cn=pwdDefault,ou=policies,dc=example" ppolicy_use_lockout ppolicy_hash_cleartext lastmod on access to attrs=userPassword by dn="cn=admin,dc=example" write by dn="uid=mirrormode,dc=example" read by dn="cn=acadmin,dc=example" write by dn="cn=rsasecureid,dc=example" auth by anonymous auth by dn="uid=test,ou=People,dc=example" none by dn="cn=iam,dc=example" write by * none access to attrs=shadowLastChange by dn="cn=admin,dc=example" write by dn="uid=mirrormode,dc=example" read by dn="cn=acadmin,dc=example" write by dn="uid=test,ou=People,dc=example" none by dn="cn=iam,dc=example" write by * read access to dn="uid=test,ou=People,dc=example" by dn="cn=admin,dc=example" write by * read access to * by dn="uid=test,ou=People,dc=example" none by dn="uid=mirrormode,dc=example" read by dn="cn=admin,dc=example" write by dn="cn=acadmin,dc=example" write by dn="cn=iam,dc=example" write by * read access to dn="ou=People,dc=example" by dn="cn=acadmin,dc=example" write by * read database monitor access to * by * read --------------------------- In the log of the slave, I get at the end: May 17 16:37:12 rada slapd[546]: ==> bdb_bind: dn: uid=user1,ou=People,dc=example May 17 16:37:12 rada slapd[546]: bdb_dn2entry("uid=user1,ou=people,dc=example") May 17 16:37:12 rada slapd[546]: => access_allowed: result not in cache (userPassword) May 17 16:37:12 rada slapd[546]: => access_allowed: auth access to "uid=user1,ou=People,dc=example" "userPassword" requested May 17 16:37:12 rada slapd[546]: => acl_get: [1] attr userPassword May 17 16:37:12 rada slapd[546]: => acl_mask: access to entry "uid=user1,ou=People,dc=example", attr "userPassword" requested May 17 16:37:12 rada slapd[546]: => acl_mask: to value by "", (=0) May 17 16:37:12 rada slapd[546]: <= check a_dn_pat: cn=admin,dc=example May 17 16:37:12 rada slapd[546]: <= check a_dn_pat: cn=acadmin,dc=example May 17 16:37:12 rada slapd[546]: <= check a_dn_pat: uid=mirrormode,dc=example May 17 16:37:12 rada slapd[546]: <= check a_dn_pat: uid=rsasecureid,dc=example May 17 16:37:12 rada slapd[546]: <= check a_dn_pat: ou=capge002,ou=application,dc=example May 17 16:37:12 rada slapd[546]: <= check a_dn_pat: anonymous May 17 16:37:12 rada slapd[546]: <= acl_mask: [6] applying auth(=xd) (stop) May 17 16:37:12 rada slapd[546]: <= acl_mask: [6] mask: auth(=xd) May 17 16:37:12 rada slapd[546]: => slap_access_allowed: auth access granted by auth(=xd) May 17 16:37:12 rada slapd[546]: => access_allowed: auth access granted by auth(=xd) May 17 16:37:12 rada slapd[546]: send_ldap_result: conn=1000 op=0 p=3 May 17 16:37:12 rada slapd[546]: send_ldap_result: err=49 matched="" text="" May 17 16:37:12 rada slapd[546]: => bdb_entry_get: ndn: "uid=user1,ou=people,dc=example" May 17 16:37:12 rada slapd[546]: => bdb_entry_get: oc: "(null)", at: "(null)" May 17 16:37:12 rada slapd[546]: bdb_dn2entry("uid=user1,ou=people,dc=example") May 17 16:37:12 rada slapd[546]: => bdb_entry_get: found entry: "uid=user1,ou=people,dc=example" May 17 16:37:12 rada slapd[546]: bdb_entry_get: rc=0 May 17 16:37:12 rada slapd[546]: bdb_dn2entry("uid=user1,ou=people,dc=example") May 17 16:37:12 rada slapd[546]: send_ldap_result: conn=1000 op=0 p=3 May 17 16:37:12 rada slapd[546]: send_ldap_result: err=10 matched="" text="" May 17 16:37:12 rada slapd[546]: send_ldap_result: referral="ldaps://simby.example:637/uid=user1,ou=People,dc=example" May 17 16:37:12 rada slapd[546]: >>> dnPrettyNormal: <uid=user1,ou=People,dc=example> May 17 16:37:12 rada slapd[546]: <<< dnPrettyNormal: <uid=user1,ou=People,dc=example>, <uid=user1,ou=people,dc=example> May 17 16:37:12 rada slapd[546]: conn=1000 op=0 ldap_chain_op: ref="ldaps://simby.example:637/uid=user1,ou=People,dc=example" -> "ldaps://simby.example:637" May 17 16:37:12 rada slapd[546]: conn=1000 op=0 ldap_chain_op: ref="ldaps://simby.example:637/uid=user1,ou=People,dc=example": URI="ldaps://simby.example:637" found in cache May 17 16:37:12 rada slapd[546]: =>ldap_back_getconn: conn=1000 op=0: lc=0x838b4a8 inserted refcnt=1 rc=0 May 17 16:37:12 rada slapd[546]: daemon: activity on 1 descriptor May 17 16:37:12 rada slapd[546]: daemon: activity on: May 17 16:37:12 rada slapd[546]: May 17 16:37:12 rada slapd[546]: daemon: epoll: listen=7 active_threads=1 tvp=zero May 17 16:37:12 rada slapd[546]: daemon: epoll: listen=8 active_threads=1 tvp=zero May 17 16:37:12 rada slapd[546]: daemon: epoll: listen=9 active_threads=1 tvp=zero May 17 16:37:12 rada slapd[546]: daemon: epoll: listen=10 active_threads=1 tvp=zero and then the slave crashes with a code 0177 In the log of the master, I get: May 17 16:37:12 simby slapd[18544]: => slap_access_allowed: auth access granted by auth(=xd) May 17 16:37:12 simby slapd[18544]: => access_allowed: auth access granted by auth(=xd) May 17 16:37:12 simby slapd[18544]: conn=1001 op=0 BIND dn="uid=mirrormode,dc=example" mech=SIMPLE ssf=0 May 17 16:37:12 simby slapd[18544]: do_bind: v3 bind: "uid=mirrormode,dc=example" to "uid=mirrormode,dc=example" May 17 16:37:12 simby slapd[18544]: send_ldap_result: conn=1001 op=0 p=3 May 17 16:37:12 simby slapd[18544]: send_ldap_result: err=0 matched="" text="" May 17 16:37:12 simby slapd[18544]: => bdb_entry_get: ndn: "uid=mirrormode,dc=example" May 17 16:37:12 simby slapd[18544]: => bdb_entry_get: oc: "(null)", at: "(null)" May 17 16:37:12 simby slapd[18544]: bdb_dn2entry("uid=mirrormode,dc=example") May 17 16:37:12 simby slapd[18544]: => bdb_entry_get: found entry: "uid=mirrormode,dc=example" May 17 16:37:12 simby slapd[18544]: bdb_entry_get: rc=0 May 17 16:37:12 simby slapd[18544]: send_ldap_response: msgid=1 tag=97 err=0 May 17 16:37:12 simby slapd[18544]: conn=1001 op=0 RESULT tag=97 err=0 text= May 17 16:37:12 simby slapd[18544]: daemon: epoll: listen=7 active_threads=0 tvp=NULL May 17 16:37:12 simby slapd[18544]: daemon: epoll: listen=8 active_threads=0 tvp=NULL May 17 16:37:12 simby slapd[18544]: daemon: epoll: listen=9 active_threads=0 tvp=NULL May 17 16:37:12 simby slapd[18544]: daemon: epoll: listen=10 active_threads=0 tvp=NULL May 17 16:37:12 simby slapd[18544]: daemon: activity on 3 descriptors May 17 16:37:12 simby slapd[18544]: daemon: activity on: May 17 16:37:12 simby slapd[18544]: 12r May 17 16:37:12 simby slapd[18544]: 15r May 17 16:37:12 simby slapd[18544]: May 17 16:37:12 simby slapd[18544]: daemon: read active on 12 May 17 16:37:12 simby slapd[18544]: connection_get(12) May 17 16:37:12 simby slapd[18544]: connection_get(12): got connid=1000 May 17 16:37:12 simby slapd[18544]: connection_read(12): checking for input on id=1000 May 17 16:37:12 simby slapd[18544]: ber_get_next on fd 12 failed errno=0 (Success) May 17 16:37:12 simby slapd[18544]: connection_read(12): input error=-2 id=1000, closing. May 17 16:37:12 simby slapd[18544]: connection_closing: readying conn=1000 sd=12 for close May 17 16:37:12 simby slapd[18544]: connection_close: conn=1000 sd=12 May 17 16:37:12 simby slapd[18544]: daemon: removing 12 May 17 16:37:12 simby slapd[18544]: conn=1000 fd=12 closed (connection lost) May 17 16:37:12 simby slapd[18544]: daemon: read active on 15 May 17 16:37:12 simby slapd[18544]: connection_get(15) May 17 16:37:12 simby slapd[18544]: connection_get(15): got connid=1001 May 17 16:37:12 simby slapd[18544]: connection_read(15): checking for input on id=1001 May 17 16:37:12 simby slapd[18544]: ber_get_next on fd 15 failed errno=0 (Success) May 17 16:37:12 simby slapd[18544]: connection_read(15): input error=-2 id=1001, closing. May 17 16:37:12 simby slapd[18544]: connection_closing: readying conn=1001 sd=15 for close May 17 16:37:12 simby slapd[18544]: connection_close: conn=1001 sd=15 May 17 16:37:12 simby slapd[18544]: daemon: removing 15 May 17 16:37:12 simby slapd[18544]: conn=1001 fd=15 closed (connection lost) May 17 16:37:12 simby slapd[18544]: daemon: epoll: listen=7 active_threads=0 tvp=NULL May 17 16:37:12 simby slapd[18544]: daemon: epoll: listen=8 active_threads=0 tvp=NULL May 17 16:37:12 simby slapd[18544]: daemon: epoll: listen=9 active_threads=0 tvp=NULL May 17 16:37:12 simby slapd[18544]: daemon: epoll: listen=10 active_threads=0 tvp=NULL May 17 16:37:12 simby slapd[18544]: daemon: activity on 1 descriptor May 17 16:37:12 simby slapd[18544]: daemon: activity on: May 17 16:37:12 simby slapd[18544]: May 17 16:37:12 simby slapd[18544]: daemon: epoll: listen=7 active_threads=0 tvp=NULL May 17 16:37:12 simby slapd[18544]: daemon: epoll: listen=8 active_threads=0 tvp=NULL May 17 16:37:12 simby slapd[18544]: daemon: epoll: listen=9 active_threads=0 tvp=NULL May 17 16:37:12 simby slapd[18544]: daemon: epoll: listen=10 active_threads=0 tvp=NULL ----------------------------- I am not sure to using the right configuration, but anyway, openldap should not crash.

1 0

Re: (ITS#8755) invalid file descriptor when closing tls connection
by ondra＠mistotebe.net 14 May '19

14 May '19

On Mon, May 13, 2019 at 03:32:19PM +0000, ondra(a)mistotebe.net wrote: > Yes, it looks like the main SockBuf closing is run twice, once in > ldap_free_connection and once directly in ldap_ld_free. I think we don't > enforce that SockBuf implementations set sb_fd != AC_SOCKET_INVALID, so > not sure yet if we can gate calling sb_close on that or something else. > > I'll see if there's a way to make this work better. There's a proposed patch at https://github.com/mistotebe/openldap/tree/its8755 -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#9008) module rpath incorrect
by quanah＠symas.com 13 May '19

13 May '19

--On Wednesday, April 17, 2019 11:19 AM +0000 ondra(a)openldap.org wrote: > Full_Name: Ondrej Kuznik > Version: re24/master > OS: Linux > URL: https://github.com/mistotebe/openldap/tree/its9008 > Submission from: (NULL) (82.10.24.68) > > > Modules that link against libraries not already present in slapd will > only try to look in the rpaths encoded in the module, not in slapd. And > there is no point encoding $(moduledir) there, since we never install > anything of substance there. All the while the libraries we need probably > live in $(libdir). > > The linked patch fixes this and makes it possible for $(moduledir) (the > path modules will be installed into) to be set at configure time. This patch depends on a custom version of libtool that is not available to others and can cause significant build breakage when building under a packaging system. More work needed, either removing libtool from the build process for OpenLDAP, or modifications to this work to allow it to work properly with a non-custom version of libtool. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8755) invalid file descriptor when closing tls connection
by ondra＠mistotebe.net 13 May '19

13 May '19

On Thu, Oct 12, 2017 at 10:01:35PM +0000, info(a)christianknueppel.de wrote: > I currently developing on a c software which is using Openldap with TLS > authentication. My software is working fine, but when i test it with valgrind, i > always get an invalid file descriptor when closing the connection. > > Here is the stacktrace from valgrind: > [...] > --> In function ldap_close_handle i call ldap_unbind_ext_s(ld, NULL, NULL). > > The connection is built with ldap_initialize(&ld, config.ldap_url) and > ldap_start_tls_s(ld, NULL, NULL). Options set with ldap_set_option() are > LDAP_OPT_X_TLS_REQUIRE_CERT to 2 (LDAP_OPT_X_TLS_DEMAND) and > LDAP_OPT_X_TLS_CACERTFILE are set to all SSL CA-Certificates > (/etc/ssl/certs/ca-certificates.crt). I run the ldap_unbind_ext_s command (for > test purpose) shortly after the start_tls command is finished. > When i use ldap_sasl_interactive_bind_s with DIGEST-MD5 instead of > ldap_start_tls_s, the warning doesn't appear. When i use both, tls and sasl, the > warning also appears. > > My computer running on Ubuntu 16.04.3 LTS (uname: 4.4.0-97-generic x86_64) with > libldap-2.4-2 (2.4.42+dfsg-2ubuntu3.2) and libgnutls30 (3.4.10-4ubuntu1.4). I > also tested it with the newest Ubuntu Artful Aardvark and the newest openldap > (2.4.45+dfsg-1ubuntu1) and gnutls(3.5.8-6ubuntu3) release, but it didn't has any > effect in my case. > > I also tryed to compiled openldap against openssl to see, if it might be a > gnutls bug, but the invalid file descriptor occurs again. The lower valgrind > stacktrace is done with openldap 2.4.45 and openssl 1.0.2g on the newest Artful > Aardvark 17.10. > [...] Yes, it looks like the main SockBuf closing is run twice, once in ldap_free_connection and once directly in ldap_ld_free. I think we don't enforce that SockBuf implementations set sb_fd != AC_SOCKET_INVALID, so not sure yet if we can gate calling sb_close on that or something else. I'll see if there's a way to make this work better. -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#8799) slaptest fails to properly convert chain configuration
by ondra＠mistotebe.net 13 May '19

13 May '19

On Wed, May 08, 2019 at 01:31:48PM +0000, ondra(a)mistotebe.net wrote: > On Mon, Jan 22, 2018 at 11:57:38PM +0000, ondra(a)mistotebe.net wrote: >> On Mon, Jan 22, 2018 at 09:59:21PM +0000, quanah(a)openldap.org wrote: >>> After doing conversion, the resulting cn=config database has *two* ldap backends >>> defined: >>> >>> dn: olcDatabase={-1}frontend,cn=config >>> dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config >>> dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=conf >> >> This is the catchall database used to handle referrals that are not >> handled by any other database you configure by hand. It collects all the >> chain-* settings that appear before the first chain-uri. >> >>> dn: olcDatabase={1}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=conf >>> >>> The first instance ({0}ldap,...) isn't even valid. If you remove the entire >>> chain configuration from this database, and then attempt to import it, you get >>> the following: >> >> Yeah that is a problem. > > Turns out the problem is different yet. When the overlay is started up > after adding its entry, it generates a default backend internally. On > adding the above backend it now thinks it has a default one already (even > though there is no entry for it yet) and rejects it. There is now a patch here that exploits the above to know if the common backend has been added from slapd.conf/explicitly or implicitly like in the original report. https://github.com/mistotebe/openldap/tree/its8799 -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#8700) Compile error
by quanah＠symas.com 10 May '19

10 May '19

--On Thursday, July 27, 2017 1:04 AM +0000 papachoco(a)gmail.com wrote: > I am getting the error below while compiling openldap 2.4.45 on the > latest macOS sierra (10.12.6). I am only setting two configuration options > > configure-options = > --disable-slapd > --disable-slurpd > > Undefined symbols for architecture x86_64: > "_ERR_remove_thread_state", referenced from: > _tlso_destroy in libldap.a(tls_o.o) Hello, What version of OpenSSL were you linking against? Thanks! --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs May 2019