openldap-bugs June 2015

openldap-bugs@openldap.org

21 participants
71 discussions

(ITS#8168) [LMDB][PATCH] Allow passing AR to make
by heirecka＠exherbo.org 11 Jun '15

11 Jun '15

Full_Name: Heiko Becker Version: OS: Linux URL: http://dev.exherbo.org/~heirecka/0001-Allow-passing-AR-to-make.patch Submission from: (NULL) (79.227.152.52) This is helpful when the ar executable is named differently, for example with an arch specific prefix. Patch available through specified URL.

1 0

RE: (ITS#8167) The new non-blocking TLS connect does not work in a reference/referral
by ipuleston＠SonicWALL.com 09 Jun '15

09 Jun '15

I've now uploaded the patch to the ftp.openldap.org FTP server as "ian-pule= ston-15069.patch". Ian

1 0

RE: (ITS#8167) The new non-blocking TLS connect does not work in a reference/referral
by ipuleston＠SonicWALL.com 09 Jun '15

09 Jun '15

Since it seems I can't send the patch file as an attachment, here it is inl= ine instead: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Start patch file =3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D --- openldap-2.4.40/libraries/libldap/tls2.c 2014-09-18 18:48:50.000000000 = -0700 +++ openldap-2.4.40-new/libraries/libldap/tls2.c 2015-06-08 19:40:30.326927= 300 -0700 @@ -842,7 +842,7 @@ * Use non-blocking io during SSL Handshake when a timeout is configured */ if ( ld->ld_options.ldo_tm_net.tv_sec >=3D 0 ) { - ber_sockbuf_ctrl( ld->ld_sb, LBER_SB_OPT_SET_NONBLOCK, sb ); + ber_sockbuf_ctrl( sb, LBER_SB_OPT_SET_NONBLOCK, (void*)1 ); ber_sockbuf_ctrl( sb, LBER_SB_OPT_GET_FD, &sd ); tv =3D ld->ld_options.ldo_tm_net; tv0 =3D tv; @@ -877,7 +877,7 @@ break; } else { /* ldap_int_poll called ldap_pvt_ndelay_off */ - ber_sockbuf_ctrl( ld->ld_sb, LBER_SB_OPT_SET_NONBLOCK, sb ); + ber_sockbuf_ctrl( sb, LBER_SB_OPT_SET_NONBLOCK, (void*)1 ); ret =3D ldap_int_tls_connect( ld, conn ); if ( ret > 0 ) { /* need to call tls_connect once more */ struct timeval curr_time_tv, delta_tv; @@ -925,7 +925,7 @@ } } if ( ld->ld_options.ldo_tm_net.tv_sec >=3D 0 ) { - ber_sockbuf_ctrl( ld->ld_sb, LBER_SB_OPT_SET_NONBLOCK, NULL ); + ber_sockbuf_ctrl( sb, LBER_SB_OPT_SET_NONBLOCK, NULL ); } #endif /* LDAP_USE_NON_BLOCKING_TLS */ =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D End patch file =3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

1 0

RE: (ITS#8167) The new non-blocking TLS connect does not work in a reference/referral
by ipuleston＠SonicWALL.com 08 Jun '15

08 Jun '15

--_002_BA45574AB547484AAB1B3380E6B1F5712C00E1AA4CUS0SCC00usson_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Attached a patch to fix this as outlined above. --_002_BA45574AB547484AAB1B3380E6B1F5712C00E1AA4CUS0SCC00usson_ Content-Type: application/octet-stream; name="openldap#8167.patch" Content-Description: openldap#8167.patch Content-Disposition: attachment; filename="openldap#8167.patch"; size=1165; creation-date="Tue, 09 Jun 2015 02:46:08 GMT"; modification-date="Tue, 09 Jun 2015 02:46:08 GMT" Content-Transfer-Encoding: base64 LS0tIG9wZW5sZGFwLTIuNC40MC9saWJyYXJpZXMvbGlibGRhcC90bHMyLmMJMjAxNC0wOS0xOCAx ODo0ODo1MC4wMDAwMDAwMDAgLTA3MDAKKysrIG9wZW5sZGFwLTIuNC40MC1uZXcvbGlicmFyaWVz L2xpYmxkYXAvdGxzMi5jCTIwMTUtMDYtMDggMTk6NDA6MzAuMzI2OTI3MzAwIC0wNzAwCkBAIC04 NDIsNyArODQyLDcgQEAKIAkgKiBVc2Ugbm9uLWJsb2NraW5nIGlvIGR1cmluZyBTU0wgSGFuZHNo YWtlIHdoZW4gYSB0aW1lb3V0IGlzIGNvbmZpZ3VyZWQKIAkgKi8KIAlpZiAoIGxkLT5sZF9vcHRp b25zLmxkb190bV9uZXQudHZfc2VjID49IDAgKSB7Ci0JCWJlcl9zb2NrYnVmX2N0cmwoIGxkLT5s ZF9zYiwgTEJFUl9TQl9PUFRfU0VUX05PTkJMT0NLLCBzYiApOworCQliZXJfc29ja2J1Zl9jdHJs KCBzYiwgTEJFUl9TQl9PUFRfU0VUX05PTkJMT0NLLCAodm9pZCopMSApOwogCQliZXJfc29ja2J1 Zl9jdHJsKCBzYiwgTEJFUl9TQl9PUFRfR0VUX0ZELCAmc2QgKTsKIAkJdHYgPSBsZC0+bGRfb3B0 aW9ucy5sZG9fdG1fbmV0OwogCQl0djAgPSB0djsKQEAgLTg3Nyw3ICs4NzcsNyBAQAogCQkJYnJl YWs7CiAJCX0gZWxzZSB7CiAJCQkvKiBsZGFwX2ludF9wb2xsIGNhbGxlZCBsZGFwX3B2dF9uZGVs YXlfb2ZmICovCi0JCQliZXJfc29ja2J1Zl9jdHJsKCBsZC0+bGRfc2IsIExCRVJfU0JfT1BUX1NF VF9OT05CTE9DSywgc2IgKTsKKwkJCWJlcl9zb2NrYnVmX2N0cmwoIHNiLCBMQkVSX1NCX09QVF9T RVRfTk9OQkxPQ0ssICh2b2lkKikxICk7CiAJCQlyZXQgPSBsZGFwX2ludF90bHNfY29ubmVjdCgg bGQsIGNvbm4gKTsKIAkJCWlmICggcmV0ID4gMCApIHsgLyogbmVlZCB0byBjYWxsIHRsc19jb25u ZWN0IG9uY2UgbW9yZSAqLwogCQkJCXN0cnVjdCB0aW1ldmFsIGN1cnJfdGltZV90diwgZGVsdGFf dHY7CkBAIC05MjUsNyArOTI1LDcgQEAKIAkJfQogCX0KIAlpZiAoIGxkLT5sZF9vcHRpb25zLmxk b190bV9uZXQudHZfc2VjID49IDAgKSB7Ci0JCWJlcl9zb2NrYnVmX2N0cmwoIGxkLT5sZF9zYiwg TEJFUl9TQl9PUFRfU0VUX05PTkJMT0NLLCBOVUxMICk7CisJCWJlcl9zb2NrYnVmX2N0cmwoIHNi LCBMQkVSX1NCX09QVF9TRVRfTk9OQkxPQ0ssIE5VTEwgKTsKIAl9CiAjZW5kaWYgLyogTERBUF9V U0VfTk9OX0JMT0NLSU5HX1RMUyAqLwogCg== --_002_BA45574AB547484AAB1B3380E6B1F5712C00E1AA4CUS0SCC00usson_--

1 0

(ITS#8167) The new non-blocking TLS connect does not work in a reference/referral
by ipuleston＠sonicwall.com 08 Jun '15

08 Jun '15

Full_Name: Ian Puleston Version: 2.4.40 OS: VxWorks URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (204.118.31.3) I've been using the new non-blocking TLS connect feature added in version 2.4.34 (issue #7428, compiled with LDAP_USE_NON_BLOCKING_TLS) and found a problem that it does not work in a reference/referral. It only works on the default connection, and that can cause a long or permanent hang in SSL_connect as follows, even when a network timeout is set and LDAP_USE_NON_BLOCKING_TLS is on: ldap_result -> ldap_chase_v3referrals ldap_chase_v3referrals -> ldap_send_server_request ldap_send_server_request -> ldap_new_connection ldap_new_connection -> ldap_int_open_connection ldap_int_open_connection -> ldap_int_tls_start ldap_int_tls_start -> ldap_pvt_tls_connect ldap_pvt_tls_connect -> (v0) tlso_session_connect -> SSL_connect The problem is that the calls to ber_sockbuf_ctrl with LBER_SB_OPT_SET_NONBLOCK pass the Sockbuf as ld->ld_sb where they should be passing it as sb, that being the Sockbuf for this connection. The following 3 changes in ldap_int_tls_start fix it: Change: ber_sockbuf_ctrl( ld->ld_sb, LBER_SB_OPT_SET_NONBLOCK, sb ); to: ber_sockbuf_ctrl( sb, LBER_SB_OPT_SET_NONBLOCK, (void*)1 ); Change: ber_sockbuf_ctrl( ld->ld_sb, LBER_SB_OPT_SET_NONBLOCK, sb ); to: ber_sockbuf_ctrl( sb, LBER_SB_OPT_SET_NONBLOCK, (void*)1 ); Change: ber_sockbuf_ctrl( ld->ld_sb, LBER_SB_OPT_SET_NONBLOCK, NULL ); to: ber_sockbuf_ctrl( sb, LBER_SB_OPT_SET_NONBLOCK, NULL )B3B Note I also changed the 3rd argument there from "sb" to "(void*)1" just because I think passing sb there is a little confusing. Either will work fine. Ian

1 0

(ITS#8166) translucent overlay - compatibility with other overlays that need write access
by thomcz＠gmail.com 08 Jun '15

08 Jun '15

Full_Name: Thomas Keil Version: 2.4.40 OS: Debian 8.0 Jessie URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (139.30.84.202) This is a software enhancement request. I have the following use case at hand: My university provides a central LDAP directory which authenticates users but does not contain group information. For my institute we want to set up our own OpenLDAP server which relays the user authentication to the central directory (via back_ldap) but additionally provides group information. This should be used by a network of linux machines for user authentication, group management and login filtering. For reasons of high availability we want to replicate our local LDAP server using the builtin replication mechanism of OpenLDAP. This seems to be a nice example for the use of the translucent backend. Nevertheless group membership (for login filtering) can only be provided using the memberof overlay which (so it seems) is not compatible with the translucent overlay. Furthermore the syncprov overlay needs to access the lastmod attribute which is disabled for databases using the translucent overlay. Thus a local database combined with the translucent overlay cannot be replicated at all. To me it seems that these problems can be solved by allowing write access to the local database for other overlays when used in combination with the translucent overlay. It would make this overlay much more useful than it is right now since it would allow to use this in large scale deployments as well (where replication is essential). This is valid especially for cases where the local administration has no write access to the central directory.

1 0

(ITS#8165) Add proper versioning to liblmdb
by quanah＠openldap.org 05 Jun '15

05 Jun '15

Full_Name: Quanah Gibson-Mount Version: HEAD OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.52.177) LMDB has matured to the point at which it should be creating a properly versioned library for linking. Currently, only liblmdb.so is created. It would be preferable to see it in libtool format (liblmdb.so.x.y.z). Should be done for the 0.9.15 release.

1 0

Re: (ITS#8164) RFC slapo-unique: set matchedDN
by pierangelo.masarati＠polimi.it 05 Jun '15

05 Jun '15

On 05/06/2015 17:41, michael(a)stroeder.com wrote: > Full_Name: Michael Str.der > Version: HEAD > OS: > URL: > Submission from: (NULL) (212.227.35.94) > > > It would be handy if slapo-unique could set matchedDN along with result code > constraintViolation(19) to a DN of an existing entry causing the constraint to > fail. I think this would violate the purpose and specification of matchedDN. It would be more appropriate to have that piece of info returned within the control value of a specifically designed response control, when the control is explicitly requested. What you're asking for could perhaps be logged, if it isn't yet. My 2c. Ciao, p. > > To avoid information disclosure ACL checking could be performed to determine > whether the bound identity has at least search privilege on the entry pseudo > attr and unique attr. > > > -- Pierangelo Masarati Associate Professor Dipartimento di Scienze e Tecnologie Aerospaziali Politecnico di Milano

1 0

(ITS#8164) RFC slapo-unique: set matchedDN
by michael＠stroeder.com 05 Jun '15

05 Jun '15

Full_Name: Michael Str.der Version: HEAD OS: URL: Submission from: (NULL) (212.227.35.94) It would be handy if slapo-unique could set matchedDN along with result code constraintViolation(19) to a DN of an existing entry causing the constraint to fail. To avoid information disclosure ACL checking could be performed to determine whether the bound identity has at least search privilege on the entry pseudo attr and unique attr.

1 0

Re: (ITS#8158) cldap broken for aix and solaris
by h.b.furuseth＠usit.uio.no 05 Jun '15

05 Jun '15

On 05. juni 2015 08:59, goran.hammarback(a)foxt.com wrote: > Yeah, the fallback... I really did not know what to use there. I knew > sizeof(struct sockaddr_storage) would work on Linux but most likely not > on Solaris and AIX, so I used sizeof(struct sockaddr). Unfortunately I > have no way of testing if that really works at all for any platform so I > guess your way is probably better... Aha! Yes, then it should be sockaddr_storage. sockaddr breaks for any address type which is bigger than sizeof(struct sockaddr), which can be small. sockaddr_storage only breaks on an OS which complains when it is too big for the specified address type. -- Hallvard

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs June 2015