RE: (ITS#8167) The new non-blocking TLS connect does not work in a reference/referral
by ipuleston＠SonicWALL.com
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
8 years, 5 months
RE: (ITS#8167) The new non-blocking TLS connect does not work in a reference/referral
by ipuleston＠SonicWALL.com
--_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_--
8 years, 5 months
(ITS#8167) The new non-blocking TLS connect does not work in a reference/referral
by ipuleston＠sonicwall.com
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
8 years, 5 months
(ITS#8166) translucent overlay - compatibility with other overlays that need write access
by thomcz＠gmail.com
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.
8 years, 5 months
(ITS#8165) Add proper versioning to liblmdb
by quanah＠openldap.org
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.
8 years, 5 months
Re: (ITS#8164) RFC slapo-unique: set matchedDN
by pierangelo.masarati＠polimi.it
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
8 years, 5 months
(ITS#8164) RFC slapo-unique: set matchedDN
by michael＠stroeder.com
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.
8 years, 5 months
Re: (ITS#8158) cldap broken for aix and solaris
by h.b.furuseth＠usit.uio.no
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
8 years, 5 months
