openldap-bugs

openldap-bugs@openldap.org

1 participants
21003 discussions

(ITS#8893) New LDAP option to support binding to specific IPv4/IPv6 address at client side
by sudhir.singam＠gmail.com 06 Aug '18

06 Aug '18

Full_Name: sudhir reddy singam Version: master branch OS: fedora URL: Submission from: (NULL) (131.228.66.13) The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by NOKIA. NOKIA has not assigned rights and/or interest in this work to any party. I, SINGAM SUDHIR REDDY authorized by NOKIA, my employer, to release this work under the following terms. NOKIA 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. **** Description: This is continuation to ITS#8847. NOKIA has decided to contribute on this small feature, that is, providing new LDAP option to be able to set the source bind IP address at openldap client side. Following are the design details of what we are planning to do. Please provide your comments for the design, so that we can proceed with the implementation. Details: Requirement: User shall be able to set multiple IPv4/IPv6 socket bind addresses, to be able to route the LDAP traffic via desired network interface. Based on the target IP address type, first matching and valid source IP address will be picked for explicit binding at client side. Work items: 1) LDAP option to set the IPv4/IPv6 socket bind addresses. Format: space separated list of IP addresses New configuration option LDAP_OPT_SOCKET_BIND_ADDRESSES (0x5013) will be introduced (in ldap.h) to be used via ldap_set_option. For example, char* p = 10.24.56.34 2001:0db8:85a3:0000:0000:8a2e:0370:7334; ldap_set_option(NULL, LDAP_OPT_SOCKET_BIND_ADDRESSES, p); Bind addresses can also be provided in ldap.conf file via the option SOCKET_BIND_ADDRESSES, for example, SOCKET_BIND_ADDRESSES 10.24.56.45 10.24.56.46 2001:0db8:85a3:0000:0000:8a2e:0370:7334 Note : Option set to ldap handle will override the global option. Setting the option multiple times will override the previous values but does not append. 2) Parsing & validations Space separated IP addresses will be parsed & validated. IPv4 and IPv6 addresses are stored separately for easy of access during connection. Basic syntax validation will be done for IPv4 or IPv6 addresses, if any error, setting of the option will fail and LDAP client will use the default IP address. ldapoptions structure in ldap-int.h will be modified to add new members "char *ldo_local_IPV4_addresses" -> to hold client local IPv4 bind addresses "char *ldo_local_IPV6_addresses" -> to hold client local IPv6 bind addresses Any new function ldap_options_parseBindAddress () will be introduced in options.c to parse, validate and store the IP addresses to respective variables. This function will be similar to ldap_url_parseHosts. Memory for ldo_local_IPV4_addresses & ldo_local_IPV6_addresses is dynamically allocated in the form of array for easy access. If any validation failure, no new memory will be allocated and existing values will be retained. 3) Using Bind IP addresses during connection File:os-ip.c Function: ldap_connect_to_host - After the connection socket is created (ldap_int_socket) and before it is connected (ldap_pvt_connect). Check if the target address family type, If it is AF_INET, IPv4 bind address list will be used. - If the list is empty and LDAP option was set successfully earlier (IPv6 was set), binding will fail and error is returned. - If the list is not empty and not able to bind to any of the provided IPv4 addresses, connection will fail. - If the list is empty and LDAP option setting failed earlier (during syntax validation), LDAP client will continue to use the kernel provided IPv4 address. If it is AF_INET6, IPv6 bind address list will be used. - If the list is empty and LDAP option was set successfully earlier (IPv4 was set), binding will fail and error is returned. - If the list is not empty and not able to bind to any of the provided IPv6 addresses, connection will fail. - If the list is empty and LDAP option setting failed earlier (during syntax validation), LDAP client will continue to use the kernel provided IPv6 address.

1 0

Re: (ITS#8892) ISC dhcpd cannot start TLS session to 389-DS after updating openldap rpm
by quanah＠symas.com 06 Aug '18

06 Aug '18

--On Monday, August 06, 2018 3:42 PM +0000 krejci(a)i3.cz wrote: > Full_Name: Mira Krejci > Version: 2.4.44-15 > OS: CentOS Linux release 7.5.1804 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (93.99.54.254) Hello, This is likely due to RedHat's customizations to the OpenLDAP libldap library. In their most recent builds, they switched from MozNSS to OpenSSL as the underlying TLS library and wrote their own custom bridging function for this change. It has apparently caused various problems for end users. I would suggest contacting RedHat or using an unmodified version of OpenLDAP. --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#8892) ISC dhcpd cannot start TLS session to 389-DS after updating openldap rpm
by michael＠stroeder.com 06 Aug '18

06 Aug '18

On 8/6/18 4:42 PM, krejci(a)i3.cz wrote: > ISC dhcp server cannot start TLS session to 389 Directory server after updating > openldap from 2.4.44-5 to newist version. > Error: Cannot start TLS session to 10.0.252.31:389: Connect error > > dhcpd version: 4.2.5-68 > 389-ds-base verson: 1.3.7.5-21 > > When I try manually copy old libraries (liblber, libldap, libslapi) back to > updated system, dhcpd works fine with TLS to 389-DS. > > We can disable TLS by "ldap-ssl off" option at /etc/dhcp/dhcpd.conf as a > workaround. The ITS is only for reporting bugs. Please post your questions on the openldap-technical mailing list: https://www.openldap.org/lists/mm/listinfo/openldap-technical Ciao, Michael.

1 0

(ITS#8892) ISC dhcpd cannot start TLS session to 389-DS after updating openldap rpm
by krejci＠i3.cz 06 Aug '18

06 Aug '18

Full_Name: Mira Krejci Version: 2.4.44-15 OS: CentOS Linux release 7.5.1804 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.99.54.254) ISC dhcp server cannot start TLS session to 389 Directory server after updating openldap from 2.4.44-5 to newist version. Error: Cannot start TLS session to 10.0.252.31:389: Connect error dhcpd version: 4.2.5-68 389-ds-base verson: 1.3.7.5-21 When I try manually copy old libraries (liblber, libldap, libslapi) back to updated system, dhcpd works fine with TLS to 389-DS. We can disable TLS by "ldap-ssl off" option at /etc/dhcp/dhcpd.conf as a workaround.

1 0

Re: (ITS#8891) LMDB fails to compile on latest Microsoft Visual Studio
by hyc＠symas.com 06 Aug '18

06 Aug '18

hrissan(a)mail.ru wrote: > Full_Name: Hrissan > Version: commit 86a90cad721cbdc0bb0a9c3bf15396f5c946ae95 > OS: Windows 7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (5.44.169.206) > > > Sorry this seems to be the only way to report bug in LMDB. No need to apologize for using the documented mechanism. Thanks for the report, fixed now in mdb.master. > > In mdb.c line 55, 68, 77 > > typedef NTSTATUS WINAPI (NtCreateSectionFunc) > > Should be > > typedef NTSTATUS (WINAPI NtCreateSectionFunc) > > Visual Studio Community 2017 version 15.7.6 does not accept the incorrect > typedef any more. > > > -- -- 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#8891) LMDB fails to compile on latest Microsoft Visual Studio
by hrissan＠mail.ru 05 Aug '18

05 Aug '18

Full_Name: Hrissan Version: commit 86a90cad721cbdc0bb0a9c3bf15396f5c946ae95 OS: Windows 7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (5.44.169.206) Sorry this seems to be the only way to report bug in LMDB. In mdb.c line 55, 68, 77 typedef NTSTATUS WINAPI (NtCreateSectionFunc) Should be typedef NTSTATUS (WINAPI NtCreateSectionFunc) Visual Studio Community 2017 version 15.7.6 does not accept the incorrect typedef any more.

1 0

Re: (ITS#8650) EAGAIN from gnutls_handshake not respected
by subbarao＠computer.org 03 Aug '18

03 Aug '18

On 08/03/2018 12:09 PM, Ryan Tandy wrote: > Thanks for letting me know about this. This patch is running on quite > a few systems by now, I'm sorry the problem wasn't caught sooner. :/ No worries, thanks for responding so quickly on this! >> I'm wondering if there is a better way to handle EAGAIN returned from >> gnutls_handshake(), instead of doing a busywait as in ITS#8650, or my >> simplistic attempt at inserting a sleep() call which doesn't really >> seem to help. I'm wondering how the GnuTLS developers intend for >> people to use gnutls_handshake() properly, so as to gracefully handle >> sessions that involve long packets on the one hand, without opening >> up a vulnerability to chew up lots of system resources on the other >> hand. > > Right. I mean, this is how GnuTLS' own example shows to do it: > > https://gitlab.com/gnutls/gnutls/blob/master/doc/examples/ex-client-dtls.c#… > Hmm, that's a head-scratcher. It doesn't seem very effective to have a non-blocking I/O interface and then recommend wrapping it in a busywait loop :-) > We could place a limit on the number of iterations, though any such > limit would have to be arbitrary. > > There might be an asynchronous GnuTLS API that could be used to avoid > tying up slapd while this is going on. > > I will look at how some other GnuTLS servers deal with this... Cool, thanks Ryan. Regards, -Kartik

1 0

Re: (ITS#8650) EAGAIN from gnutls_handshake not respected
by ryan＠nardis.ca 03 Aug '18

03 Aug '18

Hi Kartik, On Fri, Aug 03, 2018 at 11:19:06AM -0400, Kartik Subbarao wrote: >I'm running into a problem with slapd 2.4.46 hanging on Ubuntu 18.04, >which seems to be a side effect of the ITS#8650 patch: > >https://github.com/openldap/openldap/commit/7b5181da8cdd47a13041f9ee36fa959… > >slapd will run fine for a while, but during some periods of >high-traffic, it'll hang. It'll peg the CPU at 100% and won't respond >to any new LDAP connections. After some time, it'll resume working >again, but overall it's fairly unreliable. Thanks for letting me know about this. This patch is running on quite a few systems by now, I'm sorry the problem wasn't caught sooner. :/ >I'm wondering if there is a better way to handle EAGAIN returned from >gnutls_handshake(), instead of doing a busywait as in ITS#8650, or my >simplistic attempt at inserting a sleep() call which doesn't really >seem to help. I'm wondering how the GnuTLS developers intend for >people to use gnutls_handshake() properly, so as to gracefully handle >sessions that involve long packets on the one hand, without opening up >a vulnerability to chew up lots of system resources on the other hand. Right. I mean, this is how GnuTLS' own example shows to do it: https://gitlab.com/gnutls/gnutls/blob/master/doc/examples/ex-client-dtls.c#… We could place a limit on the number of iterations, though any such limit would have to be arbitrary. There might be an asynchronous GnuTLS API that could be used to avoid tying up slapd while this is going on. I will look at how some other GnuTLS servers deal with this...

1 0

Re: (ITS#8650) EAGAIN from gnutls_handshake not respected
by subbarao＠computer.org 03 Aug '18

03 Aug '18

Hi Ryan, I'm running into a problem with slapd 2.4.46 hanging on Ubuntu 18.04, which seems to be a side effect of the ITS#8650 patch: https://github.com/openldap/openldap/commit/7b5181da8cdd47a13041f9ee36fa959… slapd will run fine for a while, but during some periods of high-traffic, it'll hang. It'll peg the CPU at 100% and won't respond to any new LDAP connections. After some time, it'll resume working again, but overall it's fairly unreliable. strace on slapd during the hang shows that it's constantly making read() calls that return EAGAIN. After doing a gdb stack trace on slapd, I realized that these read() calls are happening as part of the busywait for loop in tlsg_session_accept() that repeatedly calls gnutls_handshake() when it gets EAGAIN. When slapd recovers from this hang state, the first message it prints is a TLS negotiation failure error on the culprit file descriptor. If I back out the ITS#8650 patch, the problem goes away. If I insert sleep(1) in the for loop, slapd no longer pegs the CPU at 100%, but it still becomes unresponsive during these high-traffic periods. I don't know what's happening during these high-traffic periods that causes the TLS negotiation to go astray. Unfortunately it's not easy to reproduce this problem outside of this production environment, given the diversity of clients running different OSes with various versions of SSL libraries. I'm wondering if there is a better way to handle EAGAIN returned from gnutls_handshake(), instead of doing a busywait as in ITS#8650, or my simplistic attempt at inserting a sleep() call which doesn't really seem to help. I'm wondering how the GnuTLS developers intend for people to use gnutls_handshake() properly, so as to gracefully handle sessions that involve long packets on the one hand, without opening up a vulnerability to chew up lots of system resources on the other hand. Regards, -Kartik

1 0

Re: (ITS#8890) Bug fix patches unbreaking the build on x32 systems
by tg＠debian.org 01 Aug '18

01 Aug '18

Hi, > Thanks. Most of these look OK, but the unconditional use of "long > long" instead of "long" will break on machines where "long long" is > not 64 bits. 64 bits is not the requirement for all those, but size of time_t. Each of these instances was changed from outputting a time_t with %ld (without cast to long) to outputting a time_t with %lld after being cast to long long. As long long is either the same size or greater than long, this cannot break any existing scenario. It merely fixes the scenario in which time_t is larger than long but fits into long long. (It also fixes the case where time_t is smaller than long, incidentally, as it was not cast, prior.) Actual bit sizes are of no import here due to the explicit casts, given that time_t can be of various sizes and, in constrast to e.g. size_t with its %zu specifier, does not have a printf specifier of its own. Fixing this is already common practice for me, as MirBSD/i386 is also a platform with 32-bit long and 64-bit time_t, and has been for 14 years and about five weeks or so. bye, //mirabilos -- When he found out that the m68k port was in a pretty bad shape, he did not, like many before him, shrug and move on; instead, he took it upon himself to start compiling things, just so he could compile his shell. How's that for dedication. -- Wouter, about my Debian/m68k revival

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