openldap-bugs May 2017

openldap-bugs@openldap.org

20 participants
39 discussions

Re: (ITS#8654) Option for LDAP client to bind to a local address.
by quanah＠symas.com 16 May '17

16 May '17

--On Tuesday, May 16, 2017 1:53 AM +0000 daniel.le(a)exfo.com wrote: As noted in my reply on -technical, you need to subscribe to the openldap-devel list, and have this discussion there, before starting work. Thanks! --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#8654) Option for LDAP client to bind to a local address.
by michael＠stroeder.com 16 May '17

16 May '17

daniel.le(a)exfo.com wrote: > I am not sure what "a list of space-separated addresses" exactly means. Per= > haps one IPv4 IP address and one IPv6 address if both are available. My use= > case is either a local IPv4 or IPv6 address. Hmm, a dual-stack machine is the most likely use-case. This also raises the question of the IP address list os ordered and the caller can therefore give a preference for IPv4 or IPv6 (e.g. like postfix is doing it for out-going SMTP conns). Ciao, Michael.

1 0

Re: (ITS#8654) Option for LDAP client to bind to a local address.
by daniel.le＠exfo.com 15 May '17

15 May '17

--_000_BC204A77E2E9CD4A85A8F600C7F0BA848C0F4476SPQCMBX01exfoco_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable For reference: https://msdn.microsoft.com/en-us/library/aa367019(v=3Dvs.85).aspx LDAP_OPT_SOCKET_BIND_ADDRESSES 0x44 Sets or retrieves a pointer to a TCHAR string containing a list of space-se= parated addresses to be used by socket bind. For a multihomed machine, use = this option to set a particular network interface address to be used for so= cket bind. Socket bind will be performed before socket connect for the serv= er address. See socket bind for more details. You should provide both IPv4 and IPv6 local addresses, if available, becaus= e both IPv4 and IPv6 server addresses can be used for socket connect. Socke= t bind will fail if there is an address family mismatch. On the Domain Cont= roller, for the default Server (HostName=3DNULL), loopback addresses will b= e used for socket connect. Set loopback addresses (for both IPv4 and IPv6) = for this option to work. This option can only be set before a connection is established. That is, ju= st after ldap_init. ------------------------------- I am not sure what "a list of space-separated addresses" exactly means. Per= haps one IPv4 IP address and one IPv6 address if both are available. My use= case is either a local IPv4 or IPv6 address. Daniel --_000_BC204A77E2E9CD4A85A8F600C7F0BA848C0F4476SPQCMBX01exfoco_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72"> <div class=3D"WordSection1"> For reference:<o:p></o:p> https://msdn.microsoft.com/en-us/library/aa367019(v= =3Dvs.85).aspx<o:p></o:p> <o:p> </o:p> LDAP_OPT_SOCKET_BIND_ADDRESSES<o:p></o:p> 0x44<o:p></o:p> <o:p> </o:p> Sets or retrieves a pointer to a TCHAR string contai= ning a list of space-separated addresses to be used by socket bind. For a m= ultihomed machine, use this option to set a particular network interface ad= dress to be used for socket bind. Socket bind will be performed before socket connect for the server address= . See socket bind for more details.<o:p></o:p> <o:p> </o:p> You should provide both IPv4 and IPv6 local addresse= s, if available, because both IPv4 and IPv6 server addresses can be used fo= r socket connect. Socket bind will fail if there is an address family misma= tch. On the Domain Controller, for the default Server (HostName=3DNULL), loopback addresses will be used for = socket connect. Set loopback addresses (for both IPv4 and IPv6) for this op= tion to work.<o:p></o:p> <o:p> </o:p> This option can only be set before a connection is e= stablished. That is, just after ldap_init.<o:p></o:p> <o:p> </o:p> -------------------------------<o:p></o:p> I am not sure what "a list of space-separated a= ddresses" exactly means. Perhaps one IPv4 IP address and one IPv6 addr= ess if both are available. My use case is either a local IPv4 or IPv6 addre= ss.<o:p></o:p> <o:p> </o:p> Daniel<o:p></o:p> </div> </body> </html> --_000_BC204A77E2E9CD4A85A8F600C7F0BA848C0F4476SPQCMBX01exfoco_--

1 0

RE: (ITS#8609) segfault in mods.c - modify_add_values
by henson＠acm.org 15 May '17

15 May '17

> From: Quanah Gibson-Mount > Sent: Thursday, April 20, 2017 1:26 PM > > It's fine for there to be legacy entryCSNs and a contextCSN for serverID of > 0. However, it is not fine for any master in an MMR setup to have a > specific serverID of 0. If you're running with serverID's 0-3, I'd simply > try an ldapmodify on the server with 0 to set its serverID to 4, and then > do a modification against it, so it generates a new contextCSN that gets > pushed out to all nodes. I went ahead and updated the serverID from 0 to 4 when I dropped in the patched binary, it seems to have gone smoothly. I'm planning to migrate the memberOf configuration over the summer to the dynamic list implementation, which is going to require a dump to ldif and reload, I'll go ahead and strip out the legacy serverid 0 contextCSN's then. Thanks.

1 0

RE: (ITS#8609) segfault in mods.c - modify_add_values
by henson＠acm.org 15 May '17

15 May '17

> From: Ond=C5=99ej Kuzn=C3=ADk > Sent: Thursday, April 20, 2017 1:34 AM >=20 > Would you be able to try the patch I provided earlier on one of your > servers? Sorry for the long delay on this. I had built an updated binary with the = patch, but was waiting for the server to crash to drop it in. As luck = would have it, it went almost a month without crashing 8-/. It crashed = yesterday though, so it is now running with the patch = (Ondrej-Kuznik-20170327-ITS8609-ignore-invalid-accesslog-ops.patch), = although it might take some time to see if it makes any difference. Or = it might crash again tomorrow. <sigh>. Thanks much=E2=80=A6

1 0

Re: (ITS#8654) Option for LDAP client to bind to a local address.
by hyc＠symas.com 15 May '17

15 May '17

Daniel.Le(a)Exfo.com wrote: > Full_Name: Daniel Le > Version: 2.4.44 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (107.0.5.66) > > > Enhancement request to modify the ldap_set_option function to add support for a > multihomed client to bind to a specific local network address, similarly to > "telnet -b <client-local-address>" option or Microsoft LDAP client API function > ldap_set_option(LDAP_OPT_SOCKET_BIND_ADDRESSES). It might be helpful if you would link to the documentation for this option, so someone can write something compatible. -- -- 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#8654) Option for LDAP client to bind to a local address.
by Daniel.Le＠Exfo.com 15 May '17

15 May '17

Full_Name: Daniel Le Version: 2.4.44 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (107.0.5.66) Enhancement request to modify the ldap_set_option function to add support for a multihomed client to bind to a specific local network address, similarly to "telnet -b <client-local-address>" option or Microsoft LDAP client API function ldap_set_option(LDAP_OPT_SOCKET_BIND_ADDRESSES). Thank you.

1 0

(ITS#8653) ber_flus2 assertion fail leads to a crash of slapd
by mail＠artemil.de 15 May '17

15 May '17

Full_Name: Version: 2.4.44 OS: centos 7, sles 12.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (91.224.226.197) Hello, we are trying to run openldap in a proxy mode to our AD as a virtual machine on a VMWARE ESXi 5.5. Unfortunately slapd crashes by receiving a SIGABRT very often, but not on every request. But the issue can be reproduced easily by just typing several times the "id corporateID" command. I reduced the configuration file to a minimum, - the issue remains. I'm running in to the same issue on SLES 12.2 with openldap 2.4.41 and also on a CentOS 7 with openldap 2.4.44 from the "tlb project". The crash happens, as far as i can determine, always in the ber_flush2 function after a failed assert. Here is the minimal config where the issue persists: include /usr/local/openldap/etc/openldap/schema/core.schema include /usr/local/openldap/etc/openldap/schema/cosine.schema include /usr/local/openldap/etc/openldap/schema/inetorgperson.schema include /usr/local/openldap/etc/openldap/schema/nis.schema include /usr/local/openldap/etc/openldap/schema/misc.schema pidfile /usr/local/openldap/var/run/slapd.pid argsfile /usr/local/openldap/var/run/slapd.args database ldap readonly yes protocol-version 3 rebind-as-user yes uri ldap://ldap.corp.de:389 suffix "DC=corp,DC=de" rootdn "DC=corp,DC=de?sub?&(memberof=CN=DMS-SSH-User,OU=administrative Gruppen\\, Admin- und Dienstkonten,OU=Berechtigungen,DC=corp,DC=de)" loglevel 256 Here comes the backtrace: (gdb) bt #0 0x00007ffff64281d7 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x00007ffff64298c8 in __GI_abort () at abort.c:90 #2 0x00007ffff6421146 in __assert_fail_base (fmt=0x7ffff65723a8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x649ab8 "( (sb)->sb_opts.lbo_valid == 0x3 )", file=file@entry=0x649a21 "io.c", line=line@entry=224, function=function@entry=0x649be6 <__PRETTY_FUNCTION__.6214> "ber_flush2") at assert.c:92 #3 0x00007ffff64211f2 in __GI___assert_fail (assertion=assertion@entry=0x649ab8 "( (sb)->sb_opts.lbo_valid == 0x3 )", file=file@entry=0x649a21 "io.c", line=line@entry=224, function=function@entry=0x649be6 <__PRETTY_FUNCTION__.6214> "ber_flush2") at assert.c:101 #4 0x00000000005b95d8 in ber_flush2 (sb=0x7fffe40000d8, ber=0x7fffe4119d40, freeit=freeit@entry=0) at io.c:224 #5 0x00000000005a3491 in ldap_int_flush_request (ld=ld@entry=0x7fffe8102800, lr=lr@entry=0x7fffe410d570) at request.c:186 #6 0x00000000005a38fa in ldap_send_server_request (ld=ld@entry=0x7fffe8102800, ber=ber@entry=0x7fffe4119d40, msgid=msgid@entry=134, parentreq=parentreq@entry=0x0, srvlist=srvlist@entry=0x0, lc=0x7fffe4116f70, lc@entry=0x0, bind=bind@entry=0x0, m_noconn=m_noconn@entry=0, m_res=m_res@entry=0) at request.c:408 #7 0x00000000005a3aa8 in ldap_send_initial_request (ld=ld@entry=0x7fffe8102800, msgtype=msgtype@entry=99, dn=dn@entry=0x7fffe4002e48 "dc=corp,dc=de", ber=0x7fffe4119d40, msgid=134) at request.c:169 #8 0x00000000005946e4 in ldap_pvt_search (ld=0x7fffe8102800, base=0x7fffe4002e48 "dc=corp,dc=de", scope=2, filter=filter@entry=0x7fffe40031a8 "(&(objectClass=group)(gidNumber=20000)(&(OBJECTCATEGORY=group)(gidNumber=*)))", attrs=attrs@entry=0x7fffe4003170, attrsonly=0, sctrls=0x0, cctrls=cctrls@entry=0x0, timeout=0x7ffff35d07f0, sizelimit=1, deref=0, msgidp=msgidp@entry=0x7ffff35d07cc) at search.c:128 #9 0x00000000004c902d in ldap_back_search (op=0x7fffe40028e0, rs=<optimized out>) at search.c:233 #10 0x0000000000442f41 in fe_op_search (op=0x7fffe40028e0, rs=0x7ffff35d19a0) at search.c:402 #11 0x0000000000442926 in do_search (op=0x7fffe40028e0, rs=0x7ffff35d19a0) at search.c:247 #12 0x00000000004407de in connection_operation (ctx=ctx@entry=0x7ffff35d1ad0, arg_v=arg_v@entry=0x7fffe40028e0) at connection.c:1158 #13 0x0000000000440aba in connection_read_thread (ctx=0x7ffff35d1ad0, argv=0xd) at connection.c:1294 #14 0x00000000005901c9 in ldap_int_thread_pool_wrapper (xpool=0x969360) at tpool.c:696 #15 0x00007ffff7896dc5 in start_thread (arg=0x7ffff35d2700) at pthread_create.c:308 #16 0x00007ffff64ea73d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 Here is a full backtrace: https://pastebin.com/Ya3F3WAW Thank you!

1 0

Re: (ITS#6798) Mutex starvation on two-level referral for SASL connection
by jhrozek＠redhat.com 11 May '17

11 May '17

On Wed, May 10, 2017 at 01:19:50PM -0400, Stephen Gallagher wrote: > > > On 05/10/2017 01:13 PM, Quanah Gibson-Mount wrote: > > --On Wednesday, May 10, 2017 2:09 PM -0400 Stephen Gallagher > > <sgallagh(a)redhat.com> wrote: > > > >> Sorry, I'm not sure why you're directing this at me? I've not been > >> involved with this bug at all. > > > > Hi Stephen, > > > > I'm not sure what you mean by "not involved". You are the one who > > filed the bug report with us. Here is a direct link for a refresher: > > > > <http://www.openldap.org/its/index.cgi/?findid=6798> > > > In your previous email, you sent me the ITS number 8648. I missed that > this was in reference to 6798 which I filed in 2011. > > I'm not sure if we still have a reproducer; I think we gave up years ago > on using the built-in referral tracking of libldap. I'm CCing Jakub > Hrozek who is the current tech lead on SSSD to see if he can still > reproduce the issue. I'm sorry, but I couldn't reproduce the issue any longer either. I remember from some of RH customers that they were occasionally hitting this (or similar?) issue and working around it by disabling the LDAP referral chasing in SSSD but I couldn't reproduce now on demand, sorry.

1 0

Re: (ITS#6798) Mutex starvation on two-level referral for SASL connection
by sgallagh＠redhat.com 10 May '17

10 May '17

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HHc3bK7tdjOA64tcVjmTOngCrPgq87MTg Content-Type: multipart/mixed; boundary="VicgVXOp2ABP8hIiqjm4ijIANjXR7KCdV"; protected-headers="v1" From: Stephen Gallagher <sgallagh(a)redhat.com> To: Quanah Gibson-Mount <quanah(a)symas.com>, openldap-its(a)openldap.org, Jakub Hrozek <jhrozek(a)redhat.com> Message-ID: <4b76c423-a4c3-9fc7-64e2-883388b3e65f(a)redhat.com> Subject: Re: (ITS#6798) Mutex starvation on two-level referral for SASL connection References: <D6162EF94C4315CF6F656712(a)[192.168.1.19]> <777f871f-f77e-7041-dc6a-895e1edb56a6(a)redhat.com> <WM!63a01a37caa0c6690c38e83fd6e7322d72410d224d2fdeade3b0aba909282919d8d93ff608eaaa443968f6d4f6936856!(a)mailstronghold-1.zmailcloud.com> <838E0287ACCF76C2266EC803(a)[192.168.1.19]> In-Reply-To: <838E0287ACCF76C2266EC803(a)[192.168.1.19]> --VicgVXOp2ABP8hIiqjm4ijIANjXR7KCdV Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US On 05/10/2017 01:13 PM, Quanah Gibson-Mount wrote: > --On Wednesday, May 10, 2017 2:09 PM -0400 Stephen Gallagher > <sgallagh(a)redhat.com> wrote: > >> Sorry, I'm not sure why you're directing this at me? I've not been >> involved with this bug at all. > > Hi Stephen, > > I'm not sure what you mean by "not involved". You are the one who > filed the bug report with us. Here is a direct link for a refresher: > > <http://www.openldap.org/its/index.cgi/?findid=3D6798> In your previous email, you sent me the ITS number 8648. I missed that this was in reference to 6798 which I filed in 2011. I'm not sure if we still have a reproducer; I think we gave up years ago on using the built-in referral tracking of libldap. I'm CCing Jakub Hrozek who is the current tech lead on SSSD to see if he can still reproduce the issue. --VicgVXOp2ABP8hIiqjm4ijIANjXR7KCdV-- --HHc3bK7tdjOA64tcVjmTOngCrPgq87MTg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iFwEARECAB0WIQQ0v96iCbHqLp/cLlN6JVViNrqjowUCWRNLtgAKCRB6JVViNrqj o8toAJiFVe4hmZE+5WazEAf1UrguCR0fAKCUxCVSXwgdL5eWpMtFPPgkqqaY0g== =vdhI -----END PGP SIGNATURE----- --HHc3bK7tdjOA64tcVjmTOngCrPgq87MTg--

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs May 2017