openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#8568) slapd SASL EXTERNAL bind getprop SSF bug; can provoke SEGFAULT
by michael＠stroeder.com 17 Jan '17

17 Jan '17

william.b.clay(a)acm.org wrote: > By localhost, I simply meant running the LDAP client I am developing on > the same host as slapd. To test the same code on different client > hosts, the coded test URIs always specified the server's FQDN. So you're using TLS client cert and SASL/EXTERNAL to a hostname (also in ther server cert) but where the IP address of the hostname is directly routed through 127.0.0.1? > The same tests over the same client code running on a different host > than slapd never got SEGFAULTs -- which I find curious given the nature > of that little bug. There must be some difference in OS memory > allocation logic applied in the two cases. Not sure but the difference is the client IP address. If the client can reach slapd through 127.0.0.1 the client's IP address is also 127.0.0.1 which could make a difference in the SASL client handling. Anyone said hostname canonicalization? Does setting sasl-host <fqdn> make a difference? > I recognize EXTERNAL may not be heavily used, although it's quite useful > in the environment I'm supporting. Actually I'm heavily using SASL/EXTERNAL in almost all my customer setups and in Æ-DIR using either LDAPI:// with Unix Peer Credential passing or TLS with client certs (e.g. for replication). Therefore I appreciate every fix going into this. :-) Ciao, Michael.

1 0

Re: (ITS#8568) slapd SASL EXTERNAL bind getprop SSF bug; can provoke SEGFAULT
by william.b.clay＠acm.org 17 Jan '17

17 Jan '17

By localhost, I simply meant running the LDAP client I am developing on the same host as slapd. To test the same code on different client hosts, the coded test URIs always specified the server's FQDN. The same tests over the same client code running on a different host than slapd never got SEGFAULTs -- which I find curious given the nature of that little bug. There must be some difference in OS memory allocation logic applied in the two cases. I recognize EXTERNAL may not be heavily used, although it's quite useful in the environment I'm supporting. I was simply doing exhaustive testing of my client code under all combinations of transport and authentication. With this bug plugged and using Cyrus SASL 2.1.26 at both ends (2.1.25 has a memory leak for my client), EXTERNAL runs fine in all cases: client local or remote; URI ldapi:// (auth on gid/uid), ldaps:// (auth on cert subject user DN), or ldap:// w/ startTLS (idem).

1 0

Re: (ITS#8568) slapd SASL EXTERNAL bind getprop SSF bug; can provoke SEGFAULT
by michael＠stroeder.com 16 Jan '17

16 Jan '17

william.b.clay(a)acm.org wrote: > In certain circumstances (e.g., two successive localhost EXTERNAL binds Just to be sure: What do you mean with "localhost" in this context? Really ldap://localhost or ldapi://? SASL EXTERNAL most times only makes sense in the latter case (unless you've configured a TLS certificate with name "localhost"). Ciao, Michael.

1 0

Re: (ITS#8569) manpage for autogroup
by ebackes＠symas.com 16 Jan '17

16 Jan '17

This is a multi-part message in MIME format. --Multipart=_Mon__16_Jan_2017_13_04_30_-0800_xqWAijQoRs30vwBy Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Patch attached -- Emily Backes Symas Corporation ebackes(a)symas.com desk +1 650 963 7603 mobile +1 818 620 9879 --Multipart=_Mon__16_Jan_2017_13_04_30_-0800_xqWAijQoRs30vwBy Content-Type: text/x-diff; name="0001-Add-a-manpage-for-slapo-autogroup.patch" Content-Disposition: attachment; filename="0001-Add-a-manpage-for-slapo-autogroup.patch" Content-Transfer-Encoding: quoted-printable >From b5599bce0189aaae4631b196720b69e9d8b54639 Mon Sep 17 00:00:00 2001 From: Emily Backes <ebackes(a)symas.com> Date: Mon, 16 Jan 2017 12:59:52 -0800 Subject: [PATCH] Add a manpage for slapo-autogroup --- contrib/slapd-modules/autogroup/slapo-autogroup.5 | 102 ++++++++++++++++++= ++++ 1 file changed, 102 insertions(+) create mode 100644 contrib/slapd-modules/autogroup/slapo-autogroup.5 diff --git a/contrib/slapd-modules/autogroup/slapo-autogroup.5 b/contrib/sl= apd-modules/autogroup/slapo-autogroup.5 new file mode 100644 index 0000000000..1d68a55d8a --- /dev/null +++ b/contrib/slapd-modules/autogroup/slapo-autogroup.5 @@ -0,0 +1,102 @@ +.TH SLAPO-AUTOGROUP 5 "RELEASEDATE" "OpenLDAP LDVERSION" +.\" Copyright 1998-2017 \[u00A9] The OpenLDAP Foundation, All Rights Reser= ved. +.\" Portions Copyright \[u00A9] 2007 Micha=C5=82 Szulczy=C5=84ski. +.\" Copying restrictions apply. See the COPYRIGHT file. +.\" $OpenLDAP$ +.SH NAME +\FCslapo-autogroup\FT \- automatic updates of group memberships which meet= the +requirements of any filter contained in the group definition. +.SH SYNOPSIS +In \FCslapd.conf\FT: + ... + \FCinclude ETCDIR/schema/dyngroup.schema\FT + ... + \FCmoduleload autogroup.so\FT + ... + \FCdatabase\FT ... + ... + \FCoverlay autogroup\FT + \FCautogroup-attrset groupOfURLs memberURL member\FT +.SH DESCRIPTION +The +.B autogroup +overlay to +.BR slapd (8) +allows automated updates of group memberships which meet the requirements +of any filter contained in the group definition. The filters are built from +LDAP URI-valued attributes. Any time an object is added/deleted/updated, i= t is +tested for compliance with the filters, and its membership is accordingly +updated. For searches and compares, it behaves like a static group. +If the attribute part of the URI is filled, the group entry is populated by +the values of this attribute in the entries resulting from the search. +.SH CONFIGURATION +Either +.BR \FCslapd.conf\FT (5) +or the \FCcn=3Dconfig\FT methodology of +.BR \FCslapd-config\FT (5) +may be used for configuring autogroup. Both syntaxes are provided +here for convenience: +.TP +.B \FCautogroup-attrset\FT <group-oc> <URL-ad> <member-ad> +.TP +.B \FColcAGattrSet:\FT <group-oc> <URL-ad> <member-ad> +This defines the objectclass-attribute-URI mappings defining the +automatically managed groups, and may appear multiple times. + +The value <group-oc> is the name of the objectClass that represents +the group. + +The value <URL-ad> is the name of the attributeDescription that +contains the URI that is converted to the filters. If no URI is +present, there will be no members in that group. It must be a subtype +of labeledURI. + +The value <member-ad> is the name of the attributeDescription that +specifies the member attribute. User modification of this attribute is +disabled for consistency. +.TP +.B \FCautogroup-memberof-ad\FT <memberof-ad> +.TP +.B \FColcAGmemberOfAd\FT <memberof-ad> +This defines the attribute that is used by the memberOf overlay to +store the names of groups that an entry is member of; it must be +DN-valued. It should be set to the same value as +memberof-memberof-ad. It defaults to 'memberOf'. +.SH EXAMPLES +As above in SYNOPSIS, or with memberof: + + ... + \FCinclude ETCDIR/schema/dyngroup.schema\FT + \FCinclude ETCDIR/schema/memberof.schema\FT + ... + \FCmoduleload autogroup.so\FT + \FCmoduleload memberof.so\FT + ... + \FCdatabase\FT ... + ... + \FCoverlay memberof\FT + \FCmemberof-memberof-ad\FT foo + ... + \FCoverlay autogroup\FT + \FCautogroup-attrset groupOfURLs memberURL member\FT + \FCautogroup-memberof-ad\FT foo +.SH CAVEATS +As with static groups, update operations on groups with a large number +of members may be slow. If the attribute part of the URI is specified, +modify and delete operations are more difficult to handle. In these +cases the overlay will try to detect if groups have been modified and +then simply refresh them. This can cause performance hits if the +search specified by the URI deals with a significant number of +entries. +.SH ACKNOWLEDGEMENTS +This module was originally written in 2007 by Micha=C5=82 +Szulczy=C5=84ski. Further enhancements were contributed by Howard +Chu, Raphael Ouazana, Norbert Pueschel, and Christian Manal. Manpage +updates provided by Emily Backes. +.SH SEE ALSO +.BR slapd.conf (5), +.BR slapd (8). +.SH Copyrights +Copyright \[u00A9] 1998-2017 The OpenLDAP Foundation. +Portions Copyright \[u00A9] 2007 Micha=C5=82 Szulczy=C5=84ski. +All rights reserved. --=20 2.11.0 --Multipart=_Mon__16_Jan_2017_13_04_30_-0800_xqWAijQoRs30vwBy--

1 0

(ITS#8569) manpage for autogroup
by ebackes＠symas.com 16 Jan '17

16 Jan '17

Full_Name: Emily K Backes Version: anything in the last decade OS: URL: Submission from: (NULL) (50.113.67.84) Quanah squawked at me to add the manpage for autogroup, so here it is. This is largely based on the contents of the existing README, cleaned up for ROFF as appropriate, with slapd.d style names added. I expect we'll need to add more details on delta-syncrepl compatibility after further testing is done with that. Note that default ROFF configs may not be unicode clean, but the original author's name appears to require it. For text review I recommend something like groff -mandocDutftf8 -Tutf8 slapo-autogroup.5 | less As the attached patch is directly derived from the existing README and standard OpenLDAP structures, it has the same copyright and distribution terms. Symas Corporation and myself (Emily Backes) make no further claims beyond the existing OpenLDAP Public License.

1 0

Re: (ITS#8567) Adding our Support services at your site
by quanah＠symas.com 16 Jan '17

16 Jan '17

--On Saturday, January 14, 2017 2:07 PM +0000 nickreiner(a)thishosting.rocks wrote: > Full_Name: Nick Reiner > Version: Latest > OS: Linux-based distros. > URL: http://www.openldap.org/support/ > Submission from: (NULL) (92.53.50.107) Entry added, it will show up on the website the next time it is updated. Regards, 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#8568) slapd SASL EXTERNAL bind getprop SSF bug; can provoke SEGFAULT
by quanah＠symas.com 15 Jan '17

15 Jan '17

--On Sunday, January 15, 2017 9:15 PM +0000 william.b.clay(a)acm.org wrote: > The following patch seems to correct this issue. I have tested it only on > a Debian Linux amd64 system, OpenLDAP 2.4.44 build from source, running > with Cyrus SASL 2.1.25 as distributed in Debian Wheezy. > > bill@fuji:/usr/local/src/openldap-2.4.44/servers/slapd$ diff sasl.c.orig > sasl.c 1501c1501 > < sasl_ssf_t ssf = 0; > --- >> sasl_ssf_t *ssf = NULL; > 1514c1514 > < sasl_setprop( ctx, SASL_SSF_EXTERNAL, &ssf ); > --- >> sasl_setprop( ctx, SASL_SSF_EXTERNAL, ssf ); > bill@fuji:/usr/local/src/openldap-2.4.44/servers/slapd$ Hi Bill, Thanks very much for the report! It looks like this was introduced in OpenLDAP 2.2. It's definitely not a common case. In the future, please follow the contribution guidelines documented at <http://www.openldap.org/devel/contributing.html> Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8568) slapd SASL EXTERNAL bind getprop SSF bug; can provoke SEGFAULT
by william.b.clay＠acm.org 15 Jan '17

15 Jan '17

Full_Name: Bill Clay Version: 2.4.44 OS: Debian/GNU Linux 7.8 (Wheezy) URL: Submission from: (NULL) (79.12.44.250) In sasl.c 2.4.44 slap_sasl_bind() the target variable for "sasl_getprop( ctx, SASL_SSF_EXTERNAL, (void *)&ssf );" is declared "sasl_ssf_t ssf" but sasl_getprop() needs "sasl_ssf_t *ssf". This also necessitates adjustment of the last argument of the corresponding sasl_setprop() later in the same proc. In certain circumstances (e.g., two successive localhost EXTERNAL binds with on the same LDAP connection on a Debian Linux amd64 system), this provokes a fatal slapd SIGSEGV at sasl.c:1504 due to pointer ctx corruption (low-order 4 bytes of ctx overwritten by the high-order 4 bytes of &op->o_hdr->oh_conn->c_sasl_authctx.external.ssf): (gdb) bt #0 sasl_getprop (conn=0x7f1f00007f1f, propnum=propnum@entry=102, pvalue=pvalue@entry=0x7f1faed42948) at ../../lib/common.c:1042 #1 0x000000000047105c in slap_sasl_bind (op=op@entry=0x7f1fa0002930, rs=rs@entry=0x7f1faed42a60) at sasl.c:1504 #2 0x000000000043ecf7 in fe_op_bind (op=0x7f1fa0002930, rs=0x7f1faed42a60) at bind.c:280 #3 0x000000000043e591 in do_bind (op=0x7f1fa0002930, rs=0x7f1faed42a60) at bind.c:205 #4 0x0000000000422145 in connection_operation (ctx=ctx@entry=0x7f1faed42b90, arg_v=arg_v@entry=0x7f1fa0002930) at connection.c:1158 #5 0x000000000042242e in connection_read_thread (ctx=0x7f1faed42b90, argv=<optimized out>) at connection.c:1294 #6 0x00000000004dc978 in ldap_int_thread_pool_wrapper (xpool=0x124a010) at tpool.c:696 #7 0x00007f1f5c3030a4 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #8 0x00007f1ff22f862d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 (gdb) Usually, there is no obvious impact; I have not been able to provoke the SIGSEGV except with localhost LDAP connections. The following patch seems to correct this issue. I have tested it only on a Debian Linux amd64 system, OpenLDAP 2.4.44 build from source, running with Cyrus SASL 2.1.25 as distributed in Debian Wheezy. bill@fuji:/usr/local/src/openldap-2.4.44/servers/slapd$ diff sasl.c.orig sasl.c 1501c1501 < sasl_ssf_t ssf = 0; --- > sasl_ssf_t *ssf = NULL; 1514c1514 < sasl_setprop( ctx, SASL_SSF_EXTERNAL, &ssf ); --- > sasl_setprop( ctx, SASL_SSF_EXTERNAL, ssf ); bill@fuji:/usr/local/src/openldap-2.4.44/servers/slapd$

1 0

(ITS#8567) Adding our Support services at your site
by nickreiner＠thishosting.rocks 14 Jan '17

14 Jan '17

Full_Name: Nick Reiner Version: Latest OS: Linux-based distros. URL: http://www.openldap.org/support/ Submission from: (NULL) (92.53.50.107) We'd really appreciate it if you add our support services (https://thishosting.rocks/support/) to http://www.openldap.org/support/ THR Support offers different support services, including OpenLDAP 24/7 technical support - which includes installation, maintenance, and optimization. You can use this info for our listing if you choose to add us: <a href="https://thishosting.rocks/support/">ThisHosting.Rocks Support</a> - USA THR Support offers 24/7 OpenLDAP technical support, including, but not limited to: installation, maintenance, and optimization

1 0

Re: (ITS#8566) underlying Cyrus SASL libdigestmd5 bug reportedly fixed
by hyc＠symas.com 13 Jan '17

13 Jan '17

william.b.clay(a)acm.org wrote: > Per the following, reportedly fixed in cyrus-sasl versions post-2.1.25. > > https://github.com/cyrusimap/cyrus-sasl/issues/370 > > > > Great, closing this ITS. -- -- 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

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