From marketing@rosehosting.com Tue Jan  3 10:54:07 2017
From: marketing@rosehosting.com
To: openldap-bugs@openldap.org
Subject: (ITS#8556) OpenLDAP technical support listing
Date: Tue, 03 Jan 2017 10:54:05 +0000
Message-ID: <E1cOMjF-0002LF-C1@gauss.openldap.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4274847095798777162=="

--===============4274847095798777162==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Full_Name: Michael Freeman
Version:=20
OS:=20
URL:=20
Submission from: (NULL) (206.196.115.115)


Back in 2014, we published a tutorial for OpenLDAP on our blog. You can check=
 it
out at https://www.rosehosting.com/blog/install-and-configure-openldap-and-ph=
pldapadmin-on-ubuntu-14-04/

We'd like to get listed on your OpenLDAP technical support page
(http://www.openldap.org/support/). Here's some information you can use:

<a href=3D"https://www.rosehosting.com ">Rose Web Services LLC</a> - USA=20
Provides fully managed Linux VPS hosting with free 24/7 support, free initial
OpenLDAP setup and configuration and free full weekly backups.



We'd really appreciate it if you add us to the list.


--===============4274847095798777162==--


From hyc@symas.com Tue Jan  3 19:12:57 2017
From: hyc@symas.com
To: openldap-bugs@openldap.org
Subject: Re: (ITS#8533) Support OpenSSL-1.1.0c
Date: Tue, 03 Jan 2017 19:12:55 +0000
Message-ID: <E1cOUVz-0003f1-Mk@gauss.openldap.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8909111904787293414=="

--===============8909111904787293414==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

sca(a)andreasschulze.de wrote:
> Am 28.11.2016 um 17:42 schrieb Quanah Gibson-Mount:
>> I have a few additional comments:
>> ...
>
> I updated the patch as suggested: ftp://ftp.openldap.org/incoming/andreas-s=
chulze-161204.patch

+/* REVIEW: CRYPTO_num_locks is defined as "(1)" openssl-1.1.0 */
+static ldap_pvt_thread_mutex_t	tlso_mutexes[CRYPTO_num_locks()];

This is not acceptable. The fact that the macro is defined as a function macr=
o=20
implies that it may be turned into a genuine function at some point in the=20
future. Either we get a commitment from the OpenSSL developers that this macr=
o=20
will always be a constant, or the code must change to dynamically allocate th=
e=20
mutexes array.

@@ -882,6 +924,9 @@ static BIO_METHOD tlso_bio_method =3D
  	tlso_bio_create,
  	tlso_bio_destroy
  };
+#else
+static BIO_METHOD *tlso_bio_method =3D NULL;
+#endif

  static int
  tlso_sb_setup( Sockbuf_IO_Desc *sbiod, void *arg )
@@ -898,8 +943,29 @@ tlso_sb_setup( Sockbuf_IO_Desc *sbiod, void *arg )
  =09
  	p->session =3D arg;
  	p->sbiod =3D sbiod;
+#if OPENSSL_VERSION_NUMBER < 0x10100000L
  	bio =3D BIO_new( &tlso_bio_method );
  	bio->ptr =3D (void *)p;
+#else
+	if ( tlso_bio_method =3D=3D NULL ) {
+		tlso_bio_method =3D BIO_meth_new(( 100 | 0x400 ), "sockbuf glue");
+		if ( tlso_bio_method =3D=3D NULL
+		     || !BIO_meth_set_write(tlso_bio_method, tlso_bio_write)
+		     || !BIO_meth_set_read(tlso_bio_method, tlso_bio_read)
+		     || !BIO_meth_set_puts(tlso_bio_method, tlso_bio_puts)
+		     || !BIO_meth_set_gets(tlso_bio_method, tlso_bio_gets)
+		     || !BIO_meth_set_ctrl(tlso_bio_method, tlso_bio_ctrl)
+		     || !BIO_meth_set_create(tlso_bio_method, tlso_bio_create)
+		     || !BIO_meth_set_destroy(tlso_bio_method, tlso_bio_destroy)) {
+			return -1;
+		}
+	}
+	bio =3D BIO_new(tlso_bio_method);
+	if ( bio =3D=3D NULL ) {
+		return -1;
+	}
+	BIO_set_data(bio, (void *)p);
+#endif

This is no good, the tlso_bio_method must be initialized once and only once. =

The structure can be referenced simultaneously from multiple threads, and=20
initing on each use will be a performance hit as well as a waste of memory.

--=20
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/




--===============8909111904787293414==--


From quanah@symas.com Tue Jan  3 20:16:47 2017
From: quanah@symas.com
To: openldap-bugs@openldap.org
Subject: Re: (ITS#8556) OpenLDAP technical support listing
Date: Tue, 03 Jan 2017 20:16:46 +0000
Message-ID: <E1cOVVm-0004uj-7O@gauss.openldap.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1196099984259860233=="

--===============1196099984259860233==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

--On Tuesday, January 03, 2017 10:54 AM +0000 marketing(a)rosehosting.com 
wrote:

> We'd really appreciate it if you add us to the list.

Done, and will be listed on the next website push, which will coincide with 
the OpenLDAP 2.4.45 release (So may be a little bit).

Regards,
Quanah



--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>





--===============1196099984259860233==--


From lazarev.michael@gmail.com Tue Jan  3 21:04:59 2017
From: lazarev.michael@gmail.com
To: openldap-bugs@openldap.org
Subject: (ITS#8557) mdb_put may cause a cursor malfunction
Date: Tue, 03 Jan 2017 21:04:58 +0000
Message-ID: <E1cOWGQ-00062x-Ab@gauss.openldap.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4063961640916710913=="

--===============4063961640916710913==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Full_Name: Michael Lazarev
Version: 
OS: Linux, FreeBSD
URL: ftp://ftp.openldap.org/incoming/mdb_put_test.c
Submission from: (NULL) (128.70.151.136)


After a number of mdb_put calls, mdb_cursor_get with MDB_LAST operation
positions the cursor incorrectly. Test code is submitted here:
ftp://ftp.openldap.org/incoming/mdb_put_test.c


--===============4063961640916710913==--


From sca@andreasschulze.de Tue Jan  3 22:10:48 2017
From: sca@andreasschulze.de
To: openldap-bugs@openldap.org
Subject: Re: (ITS#8533) Support OpenSSL-1.1.0c
Date: Tue, 03 Jan 2017 22:10:46 +0000
Message-ID: <E1cOXI6-000073-Ao@gauss.openldap.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6791007339587758787=="

--===============6791007339587758787==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable



Am 03.01.2017 um 20:12 schrieb Howard Chu:
> sca(a)andreasschulze.de wrote:
>> Am 28.11.2016 um 17:42 schrieb Quanah Gibson-Mount:
>>> I have a few additional comments:
>>> ...
>>
>> I updated the patch as suggested: ftp://ftp.openldap.org/incoming/andreas-=
schulze-161204.patch
>=20
> +/* REVIEW: CRYPTO_num_locks is defined as "(1)" openssl-1.1.0 */
> +static ldap_pvt_thread_mutex_t    tlso_mutexes[CRYPTO_num_locks()];
>=20
> This is not acceptable. The fact that the macro is defined as a function ma=
cro implies that it may be turned into a genuine function at some point in th=
e future. Either we get a commitment from the OpenSSL developers that this ma=
cro will always be a constant, or the code must change to dynamically allocat=
e the mutexes array.
>=20
> @@ -882,6 +924,9 @@ static BIO_METHOD tlso_bio_method =3D
>      tlso_bio_create,
>      tlso_bio_destroy
>  };
> +#else
> +static BIO_METHOD *tlso_bio_method =3D NULL;
> +#endif
>=20
>  static int
>  tlso_sb_setup( Sockbuf_IO_Desc *sbiod, void *arg )
> @@ -898,8 +943,29 @@ tlso_sb_setup( Sockbuf_IO_Desc *sbiod, void *arg )
>    =20
>      p->session =3D arg;
>      p->sbiod =3D sbiod;
> +#if OPENSSL_VERSION_NUMBER < 0x10100000L
>      bio =3D BIO_new( &tlso_bio_method );
>      bio->ptr =3D (void *)p;
> +#else
> +    if ( tlso_bio_method =3D=3D NULL ) {
> +        tlso_bio_method =3D BIO_meth_new(( 100 | 0x400 ), "sockbuf glue");
> +        if ( tlso_bio_method =3D=3D NULL
> +             || !BIO_meth_set_write(tlso_bio_method, tlso_bio_write)
> +             || !BIO_meth_set_read(tlso_bio_method, tlso_bio_read)
> +             || !BIO_meth_set_puts(tlso_bio_method, tlso_bio_puts)
> +             || !BIO_meth_set_gets(tlso_bio_method, tlso_bio_gets)
> +             || !BIO_meth_set_ctrl(tlso_bio_method, tlso_bio_ctrl)
> +             || !BIO_meth_set_create(tlso_bio_method, tlso_bio_create)
> +             || !BIO_meth_set_destroy(tlso_bio_method, tlso_bio_destroy)) {
> +            return -1;
> +        }
> +    }
> +    bio =3D BIO_new(tlso_bio_method);
> +    if ( bio =3D=3D NULL ) {
> +        return -1;
> +    }
> +    BIO_set_data(bio, (void *)p);
> +#endif
>=20
> This is no good, the tlso_bio_method must be initialized once and only once=
. The structure can be referenced simultaneously from multiple threads, and i=
niting on each use will be a performance hit as well as a waste of memory.

Hello Howard,

looks like you're much more familiar with open[ssl|ldap] insides. My intensio=
n was to show a way to build openldap with openssl-1.1.0.
I'm aware that is not ideal and you prove that now.
Thanks. But I cannot contribute better code. Sorry.

Andreas




--===============6791007339587758787==--


From h.b.furuseth@usit.uio.no Thu Jan  5 08:47:49 2017
From: h.b.furuseth@usit.uio.no
To: openldap-bugs@openldap.org
Subject: Re: (ITS#8557) mdb_put may cause a cursor malfunction
Date: Thu, 05 Jan 2017 08:47:47 +0000
Message-ID: <E1cP3i7-0007iv-Su@gauss.openldap.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3498186788081278725=="

--===============3498186788081278725==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On 03/01/17 22:04, lazarev.michael(a)gmail.com wrote:
> After a number of mdb_put calls, mdb_cursor_get with MDB_LAST operation
> positions the cursor incorrectly. Test code is submitted here:
> ftp://ftp.openldap.org/incoming/mdb_put_test.c

The C_EOF flag is doubly broken here, and maybe ill-defined:

Previous mdb_cursor_last() set C_EOF as a "cursor is on the last page"
hint, cursor_put() did not clear it in this cursor when putting
through another cursor, and then next cursor_last() uses the hint in
"if (!(mc->mc_flags & C_EOF))" when the cursor is no longer at the end.

However, elsewhere the flag is seen as "cursor is beyond last item":
mdb_cursor_next(), MDB_GET_MULTIPLE, mdb_cursor_count().  It is set
that way after mdb_cursor_sibling(<right>) fails.  But it's not used
consistently that way either: At least MDB_GET_CURRENT, MDB_PREV,
put(MDB_CURRENT) succeed with C_EOF set.  (And they don't move
the cursor to the last item first.)

As for the "cursor is on last page" hint, page_search() & co could at
least avoid some page_get()s without using C_EOF: If C_INITIALIZED is
set, then while mc_pg[] and mc_ki[] are correct it can just walk
down the cursor without doing page_get().  If a _pg or _ki needs to
change, it can switch to the regular page_seaarch() code.  Helps
write-txns and MDB_VL32, but not read-only txns.






--===============3498186788081278725==--


From hyc@symas.com Thu Jan  5 12:48:01 2017
From: hyc@symas.com
To: openldap-bugs@openldap.org
Subject: Re: (ITS#8555) slapo-pcache forgets credentials for binddn
Date: Thu, 05 Jan 2017 12:47:59 +0000
Message-ID: <E1cP7SZ-0004gd-QN@gauss.openldap.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3487362132424818033=="

--===============3487362132424818033==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

quanah(a)openldap.org wrote:
> Full_Name: Quanah Gibson-Mount
> Version: 2.4.44
> OS: Linux
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (47.208.148.26)
>
>
> When slapo-pcache is set up to use the user credentials for binding, the fi=
rst
> bind will succeed accordingly, but subsequent binds will fall back to anony=
mous,
> as slapd logs that the credentials are not found:
>
> 58645256 conn=3D1024 op=3D1 ldap_back_dobind_int: DN=3D"cn=3Djames a jones =
1,ou=3Dalumni
> association,ou=3Dpeople,dc=3Dexample,dc=3Dcom" without creds, binding
> anonymouslyldap_sasl_bind
>
>
> This is trivial to reproduce by making a slight modification to
> test020-proxycache:
>
> index f4e5cb7..105b911 100755
> --- a/tests/scripts/test020-proxycache
> +++ b/tests/scripts/test020-proxycache
> @@ -645,6 +645,22 @@ if test $RC !=3D 4 ; then
>         test $KILLSERVERS !=3D no && kill -HUP $KILLPIDS && wait
>         exit 1
>  fi
> +
> +CNT=3D`expr $CNT + 1`
> +FILTER=3D"(sn=3DJon)"
> +ATTRS=3D"cn mail telephonenumber"
> +echo "Query $CNT: (Result should not be cached)"
> +echo "# Query $CNT: (Result should not be cached)" >> $SEARCHOUT
> +$LDAPSEARCH -S "" -b "$BASEDN" -h $LOCALHOST -p $PORT2 \
> +       -D "$USERDN" -w "$UPASSWD" "$FILTER" $ATTRS >> $SEARCHOUT 2>> $TEST=
OUT
> +RC=3D$?
> +
> +if test $RC !=3D 0 ; then
> +       echo "ldapsearch failed ($RC)!"
> +       test $KILLSERVERS !=3D no && kill -HUP $KILLPIDS
> +       exit $RC
> +fi
> +
>
>
> The error test case isn't useful here, but slapd.2.log can be examined to s=
ee
> the behavior.
>
> It appears that there's a problem with this block of code in back-ldap/bind=
.c,
> that starts at line 2489 in RE24:

This title is misleading. slapo-pcache doesn't forget anything. The point is =

that when slapo-pcache is configured to cache Binds, if a Bind is answerable =

from the cache then pcache answers it and the underlying backend doesn't ever=
=20
see the Bind request.

slapo-pcache is working as designed.

back-ldap is also working as designed, in test020. In particular, it cannot d=
o=20
an authenticated connection to the remote backend unless you configure=20
proxyAuthz or rebind-as-user and neither of those are set in the test020=20
config. Without either of these possibilities for providing=20
authentication/authorization, it of course must connect anonymously to the re=
mote.

Also rebind-as-user won't work here since back-ldap only caches those=20
credentials for the duration of one session. So, the only method that will=20
work is to use proxyAuthz.

--=20
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/




--===============3487362132424818033==--


From remy.chibois@expandium.com Fri Jan  6 15:50:55 2017
From: remy.chibois@expandium.com
To: openldap-bugs@openldap.org
Subject: (ITS#8558) LMDB mdb_load plain text
Date: Fri, 06 Jan 2017 15:50:53 +0000
Message-ID: <E1cPWn7-0001H7-Rt@gauss.openldap.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3441114291797304996=="

--===============3441114291797304996==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Full_Name: Remy Chibois
Version: LMDB_0.9+
OS: Debian "Jessie"
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (46.218.8.100)


when loading data into a LMDB database using plain text mode (mdb_load -T),
escaped hexadecimal pairs (such as \09 for a tab character) cause data to be
incorrectly converted.

Replacing mdb_load.c line 251 with "*c1++ = *c2++;"nsnstead of "c1++; c2++;"
fixes the issue (after the first escaped sequence, characters from c2 pointer
need to be copied to c1 pointer in order to properly overwrite escaped
sequence).


--===============3441114291797304996==--


From matheus_morais@sicredi.com.br Fri Jan  6 18:45:01 2017
From: matheus_morais@sicredi.com.br
To: openldap-bugs@openldap.org
Subject:
 (ITS#8559) Syncrepl stuck after duplicated attribute modification on master
Date: Fri, 06 Jan 2017 18:44:59 +0000
Message-ID: <E1cPZVb-0005Cf-Pp@gauss.openldap.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3656115732448229672=="

--===============3656115732448229672==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Full_Name: Matheus Morais
Version: 2.4.42
OS: Red Hat 6
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (201.77.94.55)


In an environment with syncrepl properly configured, if one modification with
duplicated attributes values is applied on the "master" node, the "slave" stu=
ck
the replication until the entry is removed from cn=3Daccesslog.

Here is one LDIF example:

dn: ou=3Dmarili_advogados,ou=3Dterceiros,cn=3Dsistema,cn=3Dentities,dc=3Dsicr=
edi,dc=3Dcom,dc=3Dbr
changetype: modify
-
replace: SicrediEntidadePai
SicrediEntidadePai: ou=3Dterceiros,cn=3Dsistema,cn=3Dentities,dc=3Dsicredi,dc=
=3Dcom,dc=3Dbr
-
replace: SicrediEntidadePai
SicrediEntidadePai: ou=3Dterceiros,cn=3Dsistema,cn=3Dentities,dc=3Dsicredi,dc=
=3Dcom,dc=3Dbr

This change is processed by master and appears like that on the cn=3Daccesslo=
g:

dn: reqStart=3D20170103135721.000411Z,%3=3Daccesslog
objectClass: auditModify
reqStart: 20170103135721.000411Z
reqEnd: 20170103135721.000413Z
reqType: modify
reqSession: 1184351
reqAuthzID: cn=3Dmanager,dc=3Dbr
reqControls: {0}{2.16.840.1.113730.3.4.2}
reqDN: ou=3Dmarili_advogados,ou=3Dterceiros,%n=3Dsistema,cn=3Dentities,dc=3Ds=
icredi,dc=3Dc
 om,dc=3Dbr
reqResult: 0
reqMod: SicrediEntidadePai:=3D ou=3Dterceiros,cn=3Dsistema,cn=3Dentities,dc=
=3Dsicredi,dc
 =3Dcom,dc=3Dbr
reqMod: SicrediEntidadePai:=3D ou=3Dterceiros,cn=3Dsistema,cn=3Dentities,dc=
=3Dsicredi,dc
 =3Dcom,dc=3Dbr
reqMod: entryCSN:=3D 20170103135721.874447Z#000000#000#000000
reqMod: modifiersName:=3D cn=3Dmanager,dc=3Dbr
reqMod: modifyTimestamp:=3D 20170103135721Z
reqEntryUUID: 61dfd779-5799-4988-927b-914e75d6ae90

When the slaves try to apply that change, it results in a constraint violatio=
n.
We can see that kind of message on the slaves logs:

2017-01-03T19:14:21.043501-02:00 ds1openldap5p slapd[2245]:
syncrepl_message_to_op: rid=3D000 mods check (SicrediEntidadePai: multiple va=
lues
provided)
2017-01-03T19:14:21.043599-02:00 ds1openldap5p slapd[2245]: do_syncrepl% r
rid=3D000 rc 19 retrying
2017-01-03T19:15:21.039822-02:00 ds1openldap5p slapd[2245]:
syncrepl_message_to_op: rid=3D000 mods check (SicrediEntidadePai: multiple va=
lues
provided)
2017-01-03T19:15:21.039863-02:00 ds1openldap5p slapd[2245]: do_syncrepl: rid=
=3D000
rc 19 retrying

I think we have two options here:

1 - This kind of LDIF should result in a constraint violation on the master n=
ode
and the modification is not recorded on cn=3Daccesslog.
2 - The accesslog overlay should remove the duplicated values from attributes.

The first option seems more rational IMHO.


--===============3656115732448229672==--


From rick@openfortress.nl Fri Jan  6 19:17:11 2017
From: rick@openfortress.nl
To: openldap-bugs@openldap.org
Subject: (ITS#8560) Proxy Authorization is mentioned as a SASL mech
Date: Fri, 06 Jan 2017 19:17:06 +0000
Message-ID: <E1cPa0g-00063r-O5@gauss.openldap.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7153200242699411952=="

--===============7153200242699411952==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Full_Name: Rick van Rein
Version: 2.4
OS: N/A
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (2001:980:93a5:1:98ff:3cc8:e968:ded8)


Hello,

I found a nit in the OpenLDAP administrator's guide at
http://www.openldap.org/doc/admin24/guide.html#SASL%20Proxy%20Authorization

It mentions Proxy Authorization as a facility of SASL, something I never heard
of.  It is defined specifically for LDAP in RFC 4370.  So the chapter title, =
and
perhaps its ordering underneath SASL, are not perfect.

Good luck,
 -Rick


--===============7153200242699411952==--


From hyc@symas.com Fri Jan  6 19:36:48 2017
From: hyc@symas.com
To: openldap-bugs@openldap.org
Subject: Re: (ITS#8560) Proxy Authorization is mentioned as a SASL mech
Date: Fri, 06 Jan 2017 19:36:46 +0000
Message-ID: <E1cPaJi-0006SR-Ib@gauss.openldap.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3321499452211372421=="

--===============3321499452211372421==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

rick(a)openfortress.nl wrote:
> Full_Name: Rick van Rein
> Version: 2.4
> OS: N/A
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (2001:980:93a5:1:98ff:3cc8:e968:ded8)
>
>
> Hello,
>
> I found a nit in the OpenLDAP administrator's guide at
> http://www.openldap.org/doc/admin24/guide.html#SASL%20Proxy%20Authorization
>
> It mentions Proxy Authorization as a facility of SASL, something I never he=
ard
> of.

The fact that you've never heard of it does not indicate a bug. Read RFC2222 =

about authorization identities.

   It is defined specifically for LDAP in RFC 4370.  So the chapter title, and
> perhaps its ordering underneath SASL, are not perfect.

>
> Good luck,
>  -Rick
>
>

Closing this ITS.

--=20
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/




--===============3321499452211372421==--


From hyc@symas.com Fri Jan  6 19:51:18 2017
From: hyc@symas.com
To: openldap-bugs@openldap.org
Subject: Re: (ITS#8558) LMDB mdb_load plain text
Date: Fri, 06 Jan 2017 19:51:16 +0000
Message-ID: <E1cPaXk-0006hU-F3@gauss.openldap.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3235379284340700569=="

--===============3235379284340700569==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

remy.chibois(a)expandium.com wrote:
> Full_Name: Remy Chibois
> Version: LMDB_0.9+
> OS: Debian "Jessie"
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (46.218.8.100)
>
>
> when loading data into a LMDB database using plain text mode (mdb_load -T),
> escaped hexadecimal pairs (such as \09 for a tab character) cause data to be
> incorrectly converted.
>
> Replacing mdb_load.c line 251 with "*c1++ =3D *c2++;"nsnstead of "c1++; c2+=
+;"
> fixes the issue (after the first escaped sequence, characters from c2 point=
er
> need to be copied to c1 pointer in order to properly overwrite escaped
> sequence).
>
>
Thanks, fixed in git.

--=20
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/




--===============3235379284340700569==--


From bhalsema@purdue.edu Fri Jan  6 21:36:29 2017
From: bhalsema@purdue.edu
To: openldap-bugs@openldap.org
Subject: (ITS#8561) ppolicy overlay and MMR delta-sync lost sync on switching
 to REFRESH
Date: Fri, 06 Jan 2017 21:36:27 +0000
Message-ID: <E1cPcBX-0000ot-Pg@gauss.openldap.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1488525810368724395=="

--===============1488525810368724395==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Full_Name: Beth Halsema
Version: 2.4.44
OS: RHEL6
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (128.210.177.153)


The ppolicy overlay attempts to perform an LDAP_MOD_DELETE on attributes that
have already been removed via a SLAP_MOD_SOFTDEL.  This results in an error l=
ike
the following:

bdb_modify_internal: 16 modify/delete: pwdGraceUseTime: no such attribute
bdb_modify: modify failed (16)
send_ldap_result: conn=3D-1 op=3D0 p=3D0
send_ldap_result: err=3D16 matched=3D"" text=3D"modify/delete: pwdGraceUseTim=
e: no
such attribute"
null_callback : error code 0x10
slap_graduate_commit_csn: removing 0x7f38bc11c4c0
20170106184533.027966Z#000000#001#000000
syncrepl_message_to_op: rid=3D001 be_modify uid=3Dnd,ou=3DPeople,dc=3Dexample=
,dc=3Dcom
(16)
...
do_syncrep2: rid=3D001 delta-sync lost sync on
(reqStart=3D20170106184533.000001Z,cn=3Dlog), switching to REFRESH


I will be uploading a tarfile th c contains a test script, ldif files (used by
the test script), and a suggested patch.  We have performed limited testing
which demonstrated desirable behavior.

NOTE: The test script looks for the LDIFs in the DATADIR.  I tested the script
      using the openldap-2.4.44/tests/run script. =20



--===============1488525810368724395==--


From dpa-openldap@aegee.org Sat Jan  7 19:25:00 2017
From: dpa-openldap@aegee.org
To: openldap-bugs@openldap.org
Subject: (ITS#8562) Typos in the documentation
Date: Sat, 07 Jan 2017 19:24:58 +0000
Message-ID: <E1cPwbq-0007QT-UN@gauss.openldap.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3917752118047627829=="

--===============3917752118047627829==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Full_Name: &amp;#1044;&amp;#1080;&amp;#1083;&amp;#1103;&amp;#1085; &amp;#1055=
;&amp;#1072;&amp;#1083;&amp;#1072;&amp;#1091;&amp;#1079;&amp;#1086;&amp;#1074;
Version: 2.4.44
OS: any
URL:=20
Submission from: (NULL) (141.2.134.77)


In the manual,
- section 8.2.5 Access Control Examples, 2nd paragraph replace "allows anonym=
ous
to authentication against these entries" with "authenticate";
- section 13.2.4 Attibute Type Specification, 4th code snippet, replace "DESC
'common name(s) assciated with the object" with "associated";
- section8.8.1.1 LDAP Sync Replication, last paragraph, replace "is defined b=
y a
general search criteria consisting of base and scope': remove the 'a' in front
of criteria.
- section 20 Monitoring, 3rd paragraph "This information can be access with
ldapsearch", substitute with "accessed".




--===============3917752118047627829==--


From dpa-openldap@aegee.org Sat Jan  7 20:13:12 2017
From: dpa-openldap@aegee.org
To: openldap-bugs@openldap.org
Subject: (ITS#8563) Documentation inconsistency for syncrepl for mdb
Date: Sat, 07 Jan 2017 20:13:10 +0000
Message-ID: <E1cPxMU-0008Ad-Rm@gauss.openldap.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2633284547728288100=="

--===============2633284547728288100==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Full_Name: &amp;#1044;&amp;#1080;&amp;#1083;&amp;#1103;&amp;#1085; &amp;#1055=
;&amp;#1072;&amp;#1083;&amp;#1072;&amp;#1091;&amp;#1079;&amp;#1086;&amp;#1074;
Version: 2.4.44
OS: any
URL:=20
Submission from: (NULL) (141.2.134.77)


The manual states in section 5.2.5.8 olcSyncrepl, second last paragraph: "The
syncrepl replication mechanism is supported by the bdb and hdb backends".

This text above is repeated in section 6.2.3.7 syncrepl.

But in section 18.1.1.2. Syncrepl Details, fourth paragraph, is written 'The
syncrepl engine, which is a consumer-side replication engine, can work with a=
ny
backends.  The LDAP Sync provider can be configured as an overlay on any
backend, but works best with the back-bdb back-hdb, or back-mdb backends.'

Can syncrepl work with any backend and does it work with bdb equally good as
with mdb?


--===============2633284547728288100==--


From bhalsema@purdue.edu Mon Jan  9 15:55:36 2017
From: bhalsema@purdue.edu
To: openldap-bugs@openldap.org
Subject: (ITS#8564) ppolicy overlay and MMR delta-sync lost sync on switching
 to REFRESH
Date: Mon, 09 Jan 2017 15:55:35 +0000
Message-ID: <E1cQcIJ-0008Hc-8M@gauss.openldap.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7503536917702608433=="

--===============7503536917702608433==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Full_Name: Beth Halsema
Version: 2.4.44
OS: RHEL6
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (128.210.177.153)


The ppolicy overlay attempts to perform an LDAP_MOD_DELETE on attributes that
have already been removed via a SLAP_MOD_SOFTDEL.  This results in an error l=
ike
the following:

bdb_modify_internal: 16 modify/delete: pwdGraceUseTime: no such attribute
bdb_modify: modify failed (16)
send_ldap_result: conn=3D-1 op=3D0 p=3D0
send_ldap_result: err=3D16 matched=3D"" text=3D"modify/delete: pwdGraceUseTim=
e: no
such attribute"
null_callback : error code 0x10
slap_graduate_commit_csn: removing 0x7f38bc11c4c0
20170106184533.027966Z#000000#001#000000
syncrepl_message_to_op: rid=3D001 be_modify uid=3Dnd,ou=3DPeople,dc=3Dexample=
,dc=3Dcom
(16)
...
do_syncrep2: rid=3D001 delta-sync lost sync on
(reqStart=3D20170106184533.000001Z,cn=3Dlog), switching to REFRESH


I will be uploading a tarfile th c contains a test script, ldif files (used by
the test script), and a suggested patch.  We have performed limited testing
which demonstrated desirable behavior.

NOTE: The test script looks for the LDIFs in the DATADIR.  I tested the script
      using the openldap-2.4.44/tests/run script. =20



--===============7503536917702608433==--


From bhalsema@purdue.edu Mon Jan  9 15:58:23 2017
From: bhalsema@purdue.edu
To: openldap-bugs@openldap.org
Subject: Re: (ITS#8564) ppolicy overlay and MMR delta-sync lost sync on
 switching to REFRESH
Date: Mon, 09 Jan 2017 15:58:22 +0000
Message-ID: <E1cQcKz-0008Lw-V9@gauss.openldap.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2600084107647187466=="

--===============2600084107647187466==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit


I apologize...I am not sure how I caused this to be reposted.  I apologize
for the duplicate ticket.

Beth

On Mon, 9 Jan 2017, openldap-its(a)openldap.org wrote:

> Date: Mon, 9 Jan 2017 10:55:37
> To: bhalsema(a)purdue.edu
> From: openldap-its(a)openldap.org
> Subject: Re: (ITS#8564) ppolicy overlay and  MMR delta-sync lost sync on
>     switching to REFRESH
> 
> 
> *** THIS IS AN AUTOMATICALLY GENERATED REPLY ***
> 
> Thanks for your report to the OpenLDAP Issue Tracking System.  Your
> report has been assigned the tracking number ITS#8564.
> 
> One of our support engineers will look at your report in due course.
> Note that this may take some time because our support engineers
> are volunteers.  They only work on OpenLDAP when they have spare
> time.
> 
> If you need to provide additional information in regards to your
> issue report, you may do so by replying to this message.  Note that
> any mail sent to openldap-its(a)openldap.org with (ITS#8564)
> in the subject will automatically be attached to the issue report.
> 
> 	mailto:openldap-its(a)openldap.org?subject=(ITS#8564)
> 
> You may follow the progress of this report by loading the following
> URL in a web browser:
>     http://www.OpenLDAP.org/its/index.cgi?findid=8564
> 
> Please remember to retain your issue tracking number (ITS#8564)
> on any further messages you send to us regarding this report.  If
> you don't then you'll just waste our time and yours because we
> won't be able to properly track the report.
> 
> Please note that the Issue Tracking System is not intended to
> be used to seek help in the proper use of OpenLDAP Software.
> Such requests will be closed.
> 
> OpenLDAP Software is user supported.
> 	http://www.OpenLDAP.org/support/
> 
> --------------
> Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.




--===============2600084107647187466==--


From quanah@symas.com Mon Jan  9 16:00:58 2017
From: quanah@symas.com
To: openldap-bugs@openldap.org
Subject: Re: (ITS#8564) ppolicy overlay and MMR delta-sync lost sync on
 switching to REFRESH
Date: Mon, 09 Jan 2017 16:00:57 +0000
Message-ID: <E1cQcNU-0008SB-Vn@gauss.openldap.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8269633231286378966=="

--===============8269633231286378966==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

--On Monday, January 09, 2017 3:58 PM +0000 bhalsema(a)purdue.edu wrote:

>
> I apologize...I am not sure how I caused this to be reposted.  I apologize
> for the duplicate ticket.

Thanks Beth, I'll close this one out as a duplicate.

--Quanah


--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>





--===============8269633231286378966==--


From yann-externe.soubeyrand@edf.fr Tue Jan 10 15:36:35 2017
From: yann-externe.soubeyrand@edf.fr
To: openldap-bugs@openldap.org
Subject: Re: (ITS#6825) unique_uri filter reaching beyond its intended target
Date: Tue, 10 Jan 2017 15:36:34 +0000
Message-ID: <E1cQyTS-0003zY-8p@gauss.openldap.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4858015330676886435=="

--===============4858015330676886435==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Hi,

This bug is still present in 2.4.44. Also, it seems to be the same bug
as bug #6077.

Regards

Yann Soubeyrand




--===============4858015330676886435==--


From yann-externe.soubeyrand@edf.fr Tue Jan 10 15:38:46 2017
From: yann-externe.soubeyrand@edf.fr
To: openldap-bugs@openldap.org
Subject:
 Re: (ITS#6077) Spurious uniqueness errors with filters in unique overlays
Date: Tue, 10 Jan 2017 15:38:45 +0000
Message-ID: <E1cQyVZ-00042s-6t@gauss.openldap.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8163270261245296965=="

--===============8163270261245296965==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Hi,

It seems to be the same bug as bug #6825. If so, this bug is still
present in 2.4.44.

Regards

Yann Soubeyrand




--===============8163270261245296965==--


From hyc@symas.com Wed Jan 11 11:35:06 2017
From: hyc@symas.com
To: openldap-bugs@openldap.org
Subject: Re: (ITS#8557) mdb_put may cause a cursor malfunction
Date: Wed, 11 Jan 2017 11:35:03 +0000
Message-ID: <E1cRHBH-0003Be-Nl@gauss.openldap.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5937126497660583713=="

--===============5937126497660583713==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

lazarev.michael(a)gmail.com wrote:
> Full_Name: Michael Lazarev
> Version:
> OS: Linux, FreeBSD
> URL: ftp://ftp.openldap.org/incoming/mdb_put_test.c
> Submission from: (NULL) (128.70.151.136)
>
>
> After a number of mdb_put calls, mdb_cursor_get with MDB_LAST operation
> positions the cursor incorrectly. Test code is submitted here:
> ftp://ftp.openldap.org/incoming/mdb_put_test.c
>
>
Thanks for the report. Fixed now in git.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/




--===============5937126497660583713==--


From matthieu.cerda@nbs-system.com Wed Jan 11 16:44:26 2017
From: matthieu.cerda@nbs-system.com
To: openldap-bugs@openldap.org
Subject: (ITS#8565) Clarification of the slapo-ppolicy manpage
Date: Wed, 11 Jan 2017 16:44:24 +0000
Message-ID: <E1cRM0e-0000Pi-Sy@gauss.openldap.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2283898674786538317=="

--===============2283898674786538317==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Full_Name: Matthieu Cerda
Version: 2.4.40
OS: Debian jessie
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (194.213.124.6)


Hello !

As per http://www.openldap.org/lists/openldap-technical/201701/msg00017.html I
would like to submit a small improvement to the slapo-ppolicy manpage to clar=
ify
rootdn presence / absence implications in a ppolicy enabled setup.

Here is the patch (I thing it's short enough not to justify a separate upload=
):

---8<---
>From c6c03415e73fe762ee8f77d3e3cad97834913d00 Mon Sep 17 00:00:00 2001
From: Matthieu Cerda <matthieu.cerda(a)nbs-system.com>
Date: Tue, 3 Jan 2017 14:45:37 +0100
Subject: [PATCH] Clarify slapo-ppolicy manpage about rootdn absence possible
 consequences

---
 doc/man/man5/slapo-ppolicy.5 | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/doc/man/man5/slapo-ppolicy.5 b/doc/man/man5/slapo-ppolicy.5
index 8306f9761..6d3edb9c4 100644
--- a/doc/man/man5/slapo-ppolicy.5
+++ b/doc/man/man5/slapo-ppolicy.5
@@ -28,7 +28,12 @@ Note that some of the policies do not take effect when the
operation
 is performed with the
 .B rootdn
 identity; all the operations, when performed with any other identity,
-may be subjected to constraints, like access control.
+may be subjected to constraints, like access control. It means that
+not defining a
+.B rootdn
+in your configuration is likely to lead to undesirable behavior (like
+account locking using pwdLockout not working properly) unless you have
+appropriate access control entries.
 .P
 Note that the IETF Password Policy proposal for LDAP makes sense
 when considering a single-valued password attribute, while=20
--=20
2.11.0
---8<---

Thanks in advance,
Have a nice day,
--
Matthieu Cerda


--===============2283898674786538317==--


From william.b.clay@acm.org Wed Jan 11 21:05:09 2017
From: william.b.clay@acm.org
To: openldap-bugs@openldap.org
Subject: (ITS#8566) OpenLDAP client API SASL auth memory leak
Date: Wed, 11 Jan 2017 21:05:07 +0000
Message-ID: <E1cRQ4x-0006Ww-Fh@gauss.openldap.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5494021590559349333=="

--===============5494021590559349333==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Full_Name: Bill Clay
Version: 2.4.44
OS: Debian/GNU Linux 7.8 (Wheezy)
URL:=20
Submission from: (NULL) (79.12.44.250)


Valgrind runs of a testbed script driving an OpenLDAP API client module I am
developing appear to show a consistent, reproducible memory leak ("lost memor=
y")
when using the SASL default authentication mech (DIGEST-MD5 for my system) ov=
er
any underlying transport: ldapi://, ldap://, ldaps://.  The first two transpo=
rts
show identical symptoms with or without startTLS prior to authentication.

Additional test and symptom details:

* Using the same testbed and client module and either SASL mech EXTERNAL or L=
DAP
simple bind, valgrind indicates no lost memory.

* Symptoms are constant with or without proxy authz (i.e., a SASL interactive
callback SASL_CB_USER response).

* I have not configured or tested other SASL mechs in this environment.

* The FIRST SASL authentication of a process does NOT show a memory leak.

* Each SASL authentication of a process AFTER the first shows a one additional
realloc leak of the same size (500-600 bytes depending on bind details).

* The iterative test is: [ldap_initialize()], [ldap_start_tls_s()],
ldap_sasl_interactive_bind_s(), [ldap_search_ext_s()], [ldap_whoami_s()],
[ldap_unbind_ext_s()], where [] indicates calls whose omission yields no chan=
ge
in symptoms (except initialize is always called for the first iteration of a
sequence and after an unbind; unbind is always called after the last
iteration).

Environment:

Debian 7 Wheezy

OpenLDAP v. 2.4.44 original (not Debian) source custom build:=20
./configure --sysconfdir=3D/etc --localstedirir=3D/ \
 --disable-backends --enable-mdb --enable-monitor \
 --enable-crypt --enable-cleartext \
 --with-cyrus-sasl --enable-spasswd --enable-syslog --enable-local \
 --disable-overlays --enable-memberof --enable-refint --enable-unique \
 --disable-modules --with-tls --with-threads --with-gnu-ld

Sample valgrind output (the call stack is always the same, except for exact
addresses):

bill(a)fuji:/usr/local/src/liquid_feedback_frontend-v3.2.1/lib/mldap$
LD_PRELOAD=3D/usr/local/src/liquid_feedback_frontend-v3.2.1/lib/mldap/mldap.so
valgrind --leak-check=3Dfull /usr/local/src/altit-sso/lf-ldap/mldap_full_test=
.lua
=3D=3D4149=3D=3D Memcheck, a memory error detector
=3D=3D4149=3D=3D Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et =
al.
=3D=3D4149=3D=3D Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright=
 info
=3D=3D4149=3D=3D Command: /usr/local/src/altit-sso/lf-ldap/mldap_full_test.lua
=3D=3D4149=3D=3D=20
create cctx regkey 556aeaf3c864af2e_mldap_connection, cctx=3D0699c028, stack 0
1	1	SASL bind uid %2p%p/w
enter mldap_bind(), regkey=3D556aeaf3c864af2e_mldap_connection, cctx=3D0x699c=
028
mldap_bind call ldap_initialize("ldap://fuji.pvt.suresys.com")
mldap_bind after ldap_bind(0x699cac0), cctx=3D0x699c028
	DIGEST-MD5,CRAM-MD5,NTLM
	dn:uid=3Djdoe,ou=3Dpersone,dc=3Daltraitalia,dc=3Dtest

< snip - 8 iterations removed >

10	1	SASL bind uid + p/w
enter mldap_bind(), regkey=3D556aeaf3c864af2e_mldap_connection, cctx=3D0x699c=
028
mldap_bind after ldap_bind(0x699cac0), cctx=3D0x699c028
	DIGEST-MD5,CRAM-MD5,LMLM
	dn:uid=3Djdoe,ou=3Dpersone,dc=3Daltraitalia,dc=3Dtest

unbind cctx->ldp=3D0x699cac0
exit unbind
normal termination, 10 iterations
enter mldap_gc(); cctx->ldp=3D0
exit mldap_gc()
=3D=3D4149=3D=3D=20
=3D=3D4149=3D=3D HEAP SUMMARY:
=3D=3D4149=3D=3D     in use at exit: 45,614 bytes in 334 blocks
=3D=3D4149=3D=3D   total heap usage: 3,543 allocs, 3,209 frees, 169,733,045 b=
ytes
allocated
=3D=3D4149=3D=3D=20
=3D=3D4149=3D=3D 4,896 bytes in 9 blocks are definitely lost in loss record 1=
22 of 124
=3D=3D4149=3D=3D    at 0x4C28CCE: realloc (vg_replace_malloc.c:632)
=3D=3D4149=3D=3D    by 0x7712426: _plug_buf_alloc (in
/usr/lib/x86_64-linux-gnu/sasl2/libdigestmd5.so.2.0.25)
=3D=3D4149=3D=3D    by 0x770C232: add_to_challenge (in
/usr/lib/x86_64-linux-gnu/sasl2/libdigestmd5.so.2.0.25)
=3D=3D4149=3D=3D    by 0x770E689: make_client_response (in
/r%r/lib/x86_64-linux-gnu/sasl2/libdigestmd5.so.2.0.25)
=3D=3D4149=3D=3D    by 0x770EC97: digestmd5_client_mech_step (in
/usr/lib/x86_64-linux-gnu/sasl2/libdigestmd5.so.2.0.25)
=3D=3D4149=3D=3D    by 0x5CD03AD: sasl_client_step (in
/usr/lib/x86_64-linux-gnu/libsasl2.so.2.0.25)
=3D=3D4149=3D=3D    by 0x5CD08DA: sasl_client_start (in
/usr/lib/x86_64-linux-gnu/libsasl2.so.2.0.25)
=3D=3D4149=3D=3D    by 0x405386E: ldap_int_sasl_bind (cyrus.c:510)
=3D=3D4149=3D=3D    by 0x4056E5F: ldap_sasl_interactive_bind (sasl.c:487)
=3D=3D4149=3D=3D    by 0x405702B: ldap_sasl_interactive_bind_s (sasl.c:521)
=3D=3D4149=3D=3D    by 0x4027663: mldap_bind (mldap.c:647)
=3D=3D4149=3D=3D    by 0x408C31: luaD_precall (in /usr/bin/lua5.2)
=3D=3D4149=3D=3D=20
=3D=3D4149=3D=3D LEAK SUMMARY:
=3D=3D4149=3D=3D    definitely lost: 4,896 bytes in 9 blocks
=3D=3D4149=3D=3D    indirectly lost: 0 bytes in 0 blocks
=3D=3D4149=3D=3D      possibly lost: 0 bytes in 0 blocks
=3D=3D4149=3D=3D    still reachable: 40,718 bytes in 325 blocks
=3D=3D4149=3D=3D         suppressed: 0 bytes in 0 blocks
=3D=3D4149=3D=3D Reachable blocks (those to which a pointer was found) are no=
t shown.D%D
=3D=3D4149=3D=3D To see them, rerun with: --leak-check=3Dfull --show-reachabl=
e=3Dyes
=3D=3D4149=3D=3D=20
=3D=3D4149=3D=3D For counts of detected and suppressed errors, rerun with: -v
=3D=3D4149=3D=3D ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 31 from=
 7)
bill(a)fuji:/usr/local/src/liquid_feedback_frontend-v3.2.1/lib/mldap$=20


--===============5494021590559349333==--


From william.b.clay@acm.org Thu Jan 12 07:39:05 2017
From: william.b.clay@acm.org
To: openldap-bugs@openldap.org
Subject: (ITS#8566) correction: "symptom details"
Date: Thu, 12 Jan 2017 07:39:04 +0000
Message-ID: <E1cRZyS-00079H-60@gauss.openldap.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6177077004191146194=="

--===============6177077004191146194==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

The 4th and 5th bullet points under "symptom details" of my original 
ticket text are not supported by the evidence.  Corrected replacements:

* Valgrind does NOT show lost memory after a ONE SASL authentication by 
a process.

* Valgrind shows N-1 lost memory blocks after N multiple SASL 
authentications by a process. Given the same credentials and mech, each 
such block is the same size, ca. 500-600 bytes.

On reflection, it is probably the LAST authentication that frees the 
memory block in question, although my testing seems to indicate it is 
NOT unbind() that does so; perhaps some sort of process termination 
callback in OpenLDAP, SASL, or MD5 library code?

Sorry about the initial inaccuracy.




--===============6177077004191146194==--


From hyc@symas.com Thu Jan 12 13:19:14 2017
From: hyc@symas.com
To: openldap-bugs@openldap.org
Subject: Re: (ITS#8566) OpenLDAP client API SASL auth memory leak
Date: Thu, 12 Jan 2017 13:19:12 +0000
Message-ID: <E1cRfHc-0005hX-EQ@gauss.openldap.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5399903889088239197=="

--===============5399903889088239197==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

william.b.clay(a)acm.org wrote:
> Full_Name: Bill Clay
> Version: 2.4.44
> OS: Debian/GNU Linux 7.8 (Wheezy)
> URL:
> Submission from: (NULL) (79.12.44.250)

> =3D=3D4149=3D=3D 4,896 bytes in 9 blocks are definitely lost in loss record=
 122 of 124
> =3D=3D4149=3D=3D    at 0x4C28CCE: realloc (vg_replace_malloc.c:632)
> =3D=3D4149=3D=3D    by 0x7712426: _plug_buf_alloc (in
> /usr/lib/x86_64-linux-gnu/sasl2/libdigestmd5.so.2.0.25)
> =3D=3D4149=3D=3D    by 0x770C232: add_to_challenge (in
> /usr/lib/x86_64-linux-gnu/sasl2/libdigestmd5.so.2.0.25)
> =3D=3D4149=3D=3D    by 0x770E689: make_client_response (in
> /r%r/lib/x86_64-linux-gnu/sasl2/libdigestmd5.so.2.0.25)
> =3D=3D4149=3D=3D    by 0x770EC97: digestmd5_client_mech_step (in
> /usr/lib/x86_64-linux-gnu/sasl2/libdigestmd5.so.2.0.25)

This is very clearly a leak in the digestmd5.so module. It seems you should b=
e=20
reporting this to Cyrus SASL, not us.

> =3D=3D4149=3D=3D    by 0x5CD03AD: sasl_client_step (in
> /usr/lib/x86_64-linux-gnu/libsasl2.so.2.0.25)
> =3D=3D4149=3D=3D    by 0x5CD08DA: sasl_client_start (in
> /usr/lib/x86_64-linux-gnu/libsasl2.so.2.0.25)
> =3D=3D4149=3D=3D    by 0x405386E: ldap_int_sasl_bind (cyrus.c:510)
> =3D=3D4149=3D=3D    by 0x4056E5F: ldap_sasl_interactive_bind (sasl.c:487)
> =3D=3D4149=3D=3D    by 0x405702B: ldap_sasl_interactive_bind_s (sasl.c:521)
> =3D=3D4149=3D=3D    by 0x4027663: mldap_bind (mldap.c:647)
> =3D=3D4149=3D=3D    by 0x408C31: luaD_precall (in /usr/bin/lua5.2)
> =3D=3D4149=3D=3D
> =3D=3D4149=3D=3D LEAK SUMMARY:
> =3D=3D4149=3D=3D    definitely lost: 4,896 bytes in 9 blocks
> =3D=3D4149=3D=3D    indirectly lost: 0 bytes in 0 blocks
> =3D=3D4149=3D=3D      possibly lost: 0 bytes in 0 blocks
> =3D=3D4149=3D=3D    still reachable: 40,718 bytes in 325 blocks
> =3D=3D4149=3D=3D         suppressed: 0 bytes in 0 blocks
> =3D=3D4149=3D=3D Reachable blocks (those to which a pointer was found) are =
not shown.D%D
> =3D=3D4149=3D=3D To see them, rerun with: --leak-check=3Dfull --show-reacha=
ble=3Dyes
> =3D=3D4149=3D=3D
> =3D=3D4149=3D=3D For counts of detected and suppressed errors, rerun with: =
-v
> =3D=3D4149=3D=3D ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 31 fr=
om 7)
> bill(a)fuji:/usr/local/src/liquid_feedback_frontend-v3.2.1/lib/mldap$
>
>


--=20
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/




--===============5399903889088239197==--


From bhalsema@purdue.edu Thu Jan 12 15:15:58 2017
From: bhalsema@purdue.edu
To: openldap-bugs@openldap.org
Subject: Re: (ITS#8561) ppolicy overlay and MMR delta-sync lost sync on
 switching to REFRESH
Date: Thu, 12 Jan 2017 15:15:56 +0000
Message-ID: <E1cRh6a-0008GE-Kx@gauss.openldap.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4848577896425716796=="

--===============4848577896425716796==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit


We have determined that our initial patch resulted in an undesirable side
effect (a race condition due to the "drop" code now being executed).

We are uploading a different patch.  In short, the modification is limited
to the replica handling in the ppolicy_modify() function in which we have
changed from the use of LDAP_MOD_DELETE to SLAP_MOD_SOFTDEL.  

If this is a potentially "dangerous" choice, then, please, let us know.
We would prefer to wait for your official modifications, but we understand
that the discussion and resolution may take a while.  We needed to address
the the constant syncrepl REFRESH of our large directory as it was causing
operational issues.   

Thank you! 

-------------------------------------------------------------------------
Beth A. Halsema - GSEC, GSSP-Java          email:bhalsema(a)purdue.edu
Sofware Engineer, Identity & Access Management
OVPIT - IT Security and Policy
3495 Kent Avenue, Suite 100                Fax  :  (765) 464-2233
West Lafayette, IN  47906                  Campus Mail:  ROSS




--===============4848577896425716796==--


From william.b.clay@acm.org Thu Jan 12 23:11:43 2017
From: william.b.clay@acm.org
To: openldap-bugs@openldap.org
Subject: SASL 2.0.25 libdigestmd5 memory leak [OpenLDAP (ITS#8566)]
Date: Thu, 12 Jan 2017 23:11:42 +0000
Message-ID: <E1cRoX0-0003xf-7y@gauss.openldap.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0157012512701695102=="

--===============0157012512701695102==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Greetings, SASL developers.  I recognize the version of SASL2 I'm using 
is long in tooth, but looking at the code, I believe a memory leak I've 
encountered is still present in 2.1.26 (latest source I've seen).

The problem from an OpenLDAP client viewpoint is described in detail at:

http://www.OpenLDAP.org/its/index.cgi?findid=8566

digestmd5.c sasl_client_start()/sasl_client_step(), when called for a 
new SASL DIGEST-MD5 authentication each time after the first such case, 
appear to abandon and re-allocate from scratch (without freeing) a 
[con]text->out_buf allocated and expanded during the previous 
authentication cycle by _plug_buf_alloc() on behalf of add_to_challenge().

In my case, each DIGEST-MD5 authentication after the first leaks 500-600 
bytes, regardless of whether sasl_dispose() is called between successive 
authentications.

I suspect, but have not proven, that this is because 
"text->out_buf=NULL" appears twice in digestmd5.c, in both 
make_client_response() and digestmd5_server_mech_step1().  If both 
instances were executed for one authentication cycle, it could produce 
the memory leak in question.

The latter instance (in digestmd5_server_mech_step1()) might need to 
free any block addressed by the pointer before nullifying it.  Sorry I 
can't provide a patch or stronger evidence, but the logic here is a bit 
complex for a casual onlooker to tackle.

Thanks for your efforts,
Bill Clay





--===============0157012512701695102==--


From william.b.clay@acm.org Fri Jan 13 09:40:20 2017
From: william.b.clay@acm.org
To: openldap-bugs@openldap.org
Subject: (ITS#8566) underlying Cyrus SASL libdigestmd5 bug reportedly fixed
Date: Fri, 13 Jan 2017 09:40:18 +0000
Message-ID: <E1cRyLK-0008Mr-SH@gauss.openldap.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6855674906204093498=="

--===============6855674906204093498==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Per the following, reportedly fixed in cyrus-sasl versions post-2.1.25.

https://github.com/cyrusimap/cyrus-sasl/issues/370




--===============6855674906204093498==--


From hyc@symas.com Fri Jan 13 09:55:25 2017
From: hyc@symas.com
To: openldap-bugs@openldap.org
Subject:
 Re: (ITS#8566) underlying Cyrus SASL libdigestmd5 bug reportedly fixed
Date: Fri, 13 Jan 2017 09:55:23 +0000
Message-ID: <E1cRyZv-0000K2-4P@gauss.openldap.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6700741883552349755=="

--===============6700741883552349755==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

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/




--===============6700741883552349755==--


From nickreiner@thishosting.rocks Sat Jan 14 14:07:01 2017
From: nickreiner@thishosting.rocks
To: openldap-bugs@openldap.org
Subject: (ITS#8567) Adding our Support services at your site
Date: Sat, 14 Jan 2017 14:07:00 +0000
Message-ID: <E1cSOyy-0001Z2-0k@gauss.openldap.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2454969677827592349=="

--===============2454969677827592349==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

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 techni=
cal
support - which includes installation, maintenance, and optimization.

You can use this info for our listing if you choose to add us:

<a href=3D"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


--===============2454969677827592349==--


From william.b.clay@acm.org Sun Jan 15 21:15:56 2017
From: william.b.clay@acm.org
To: openldap-bugs@openldap.org
Subject:
 (ITS#8568) slapd SASL EXTERNAL bind getprop SSF bug; can provoke SEGFAULT
Date: Sun, 15 Jan 2017 21:15:54 +0000
Message-ID: <E1cSs9a-0007aX-UU@gauss.openldap.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6322067650355938919=="

--===============6322067650355938919==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Full_Name: Bill Clay
Version: 2.4.44
OS: Debian/GNU Linux 7.8 (Wheezy)
URL:=20
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 fat=
al
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=3D0x7f1f00007f1f, propnum=3Dpropnum(a)entry=3D102,=20
    pvalue=3Dpvalue(a)entry=3D0x7f1faed42948) at ../../lib/common.c:1042
#1  0x000000000047105c in slap_sasl_bind (op=3Dop(a)entry=3D0x7f1fa0002930,
rs=3Drs(a)entry=3D0x7f1faed42a60)
    at sasl.c:1504
#2  0x000000000043ecf7 in fe_op_bind (op=3D0x7f1fa0002930, rs=3D0x7f1faed42a6=
0) at
bind.c:280
#3  0x000000000043e591 in do_bind (op=3D0x7f1fa0002930, rs=3D0x7f1faed42a60) =
at
bind.c:205
#4  0x0000000000422145 in connection_operation (ctx=3Dctx(a)entry=3D0x7f1faed=
42b90,=20
    arg_v=3Darg_v(a)entry=3D0x7f1fa0002930) at connection.c:1158
#5  0x000000000042242e in connection_read_thread (ctx=3D0x7f1faed42b90,
argv=3D<optimized out>)
    at connection.c:1294
#6  0x00000000004dc978 in ldap_int_thread_pool_wrapper (xpool=3D0x124a010) 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 SIGS=
EGV
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 Cy=
rus
SASL 2.1.25 as distributed in Debian Wheezy.

bill(a)fuji:/usr/local/src/openldap-2.4.44/servers/slapd$ diff sasl.c.orig sa=
sl.c
1501c1501
< 			sasl_ssf_t ssf =3D 0;
---
> 			sasl_ssf_t *ssf =3D NULL;
1514c1514
< 				sasl_setprop( ctx, SASL_SSF_EXTERNAL, &ssf );
---
> 				sasl_setprop( ctx, SASL_SSF_EXTERNAL, ssf );
bill(a)fuji:/usr/local/src/openldap-2.4.44/servers/slapd$


--===============6322067650355938919==--


From quanah@symas.com Sun Jan 15 23:17:26 2017
From: quanah@symas.com
To: openldap-bugs@openldap.org
Subject:
 Re: (ITS#8568) slapd SASL EXTERNAL bind getprop SSF bug; can provoke SEGFAULT
Date: Sun, 15 Jan 2017 23:17:24 +0000
Message-ID: <E1cSu3A-00018l-LR@gauss.openldap.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0454911430936058760=="

--===============0454911430936058760==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

--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(a)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(a)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>





--===============0454911430936058760==--


From quanah@symas.com Mon Jan 16 19:06:03 2017
From: quanah@symas.com
To: openldap-bugs@openldap.org
Subject: Re: (ITS#8567) Adding our Support services at your site
Date: Mon, 16 Jan 2017 19:06:02 +0000
Message-ID: <E1cTCbR-0001tg-VP@gauss.openldap.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6334147019802857999=="

--===============6334147019802857999==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

--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>





--===============6334147019802857999==--


From ebackes@symas.com Mon Jan 16 21:00:44 2017
From: ebackes@symas.com
To: openldap-bugs@openldap.org
Subject: (ITS#8569) manpage for autogroup
Date: Mon, 16 Jan 2017 21:00:43 +0000
Message-ID: <E1cTEOR-0004K0-5h@gauss.openldap.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7114125862874168318=="

--===============7114125862874168318==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Full_Name: Emily K Backes
Version: anything in the last decade
OS:=20
URL:=20
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 standa=
rd
OpenLDAP structures, it has the same copyright and distribution terms.  Symas
Corporation and myself (Emily Backes) make no further claims beyond the exist=
ing
OpenLDAP Public License.



--===============7114125862874168318==--


From ebackes@symas.com Mon Jan 16 21:04:42 2017
From: ebackes@symas.com
To: openldap-bugs@openldap.org
Subject: Re: (ITS#8569) manpage for autogroup
Date: Mon, 16 Jan 2017 21:04:40 +0000
Message-ID: <E1cTESG-0004Nr-H6@gauss.openldap.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1654392329103828602=="

--===============1654392329103828602==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

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--




--===============1654392329103828602==--


From michael@stroeder.com Tue Jan 17 07:57:20 2017
From: michael@stroeder.com
To: openldap-bugs@openldap.org
Subject:
 Re: (ITS#8568) slapd SASL EXTERNAL bind getprop SSF bug; can provoke SEGFAULT
Date: Tue, 17 Jan 2017 07:57:18 +0000
Message-ID: <E1cTOdq-0000ET-QQ@gauss.openldap.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8112541421224562979=="

--===============8112541421224562979==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

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.





--===============8112541421224562979==--


From william.b.clay@acm.org Tue Jan 17 09:38:24 2017
From: william.b.clay@acm.org
To: openldap-bugs@openldap.org
Subject:
 Re: (ITS#8568) slapd SASL EXTERNAL bind getprop SSF bug; can provoke SEGFAULT
Date: Tue, 17 Jan 2017 09:38:23 +0000
Message-ID: <E1cTQDf-0002gp-5y@gauss.openldap.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3688590403190268610=="

--===============3688590403190268610==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

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).




--===============3688590403190268610==--


From michael@stroeder.com Tue Jan 17 11:36:00 2017
From: michael@stroeder.com
To: openldap-bugs@openldap.org
Subject:
 Re: (ITS#8568) slapd SASL EXTERNAL bind getprop SSF bug; can provoke SEGFAULT
Date: Tue, 17 Jan 2017 11:35:57 +0000
Message-ID: <E1cTS3R-0005GX-Es@gauss.openldap.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3517970486113704442=="

--===============3517970486113704442==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

william.b.clay(a)acm.org wrote:
> By localhost, I simply meant running the LDAP client I am developing on=20
> the same host as slapd.  To test the same code on different client=20
> 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 thro=
ugh
127.0.0.1?

> The same tests over the same client code running on a different host=20
> than slapd never got SEGFAULTs -- which I find curious given the nature=20
> of that little bug. There must be some difference in OS memory=20
> 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=20
> in the environment I'm supporting.

Actually I'm heavily using SASL/EXTERNAL in almost all my customer setups and=
 in
=C3=86-DIR using either LDAPI:// with Unix Peer Credential passing or TLS wit=
h client
certs (e.g. for replication).

Therefore I appreciate every fix going into this. :-)

Ciao, Michael.




--===============3517970486113704442==--


From okuznik@symas.com Tue Jan 17 11:49:34 2017
From: okuznik@symas.com
To: openldap-bugs@openldap.org
Subject: (ITS#8570) Typo in LDAP_STAILQ_ENTRY_INIT
Date: Tue, 17 Jan 2017 11:49:32 +0000
Message-ID: <E1cTSGa-0005YM-Ir@gauss.openldap.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4891713853323907531=="

--===============4891713853323907531==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Full_Name: Ondrej Kuznik
Version: master
OS:=20
URL: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170117-ldap_queue-STAILQ=
.patch
Submission from: (NULL) (151.228.185.198)


There is a typo in include/ldap_queue.h:227, where the macro arguments do not
match with the content. Patch attached.


--===============4891713853323907531==--


From quanah@symas.com Tue Jan 17 17:58:53 2017
From: quanah@symas.com
To: openldap-bugs@openldap.org
Subject: Re: (ITS#8570) Typo in LDAP_STAILQ_ENTRY_INIT
Date: Tue, 17 Jan 2017 17:58:51 +0000
Message-ID: <E1cTY1z-0004CK-TD@gauss.openldap.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============9205355677000938227=="

--===============9205355677000938227==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

--On Tuesday, January 17, 2017 11:49 AM +0000 okuznik(a)symas.com wrote:

> Full_Name: Ondrej Kuznik
> Version: master
> OS:
> URL:
> ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170117-ldap_queue-STAILQ.
> patch Submission from: (NULL) (151.228.185.198)
>
>
> There is a typo in include/ldap_queue.h:227, where the macro arguments do
> not match with the content. Patch attached.

Thanks for the report!  This will be a part of the 2.4.45 release.

Regards,
Quanah

--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>





--===============9205355677000938227==--


From quanah@symas.com Tue Jan 17 18:49:10 2017
From: quanah@symas.com
To: openldap-bugs@openldap.org
Subject: Re: (ITS#8562) Typos in the documentation
Date: Tue, 17 Jan 2017 18:49:08 +0000
Message-ID: <E1cTYoe-000543-BF@gauss.openldap.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1177466000916905417=="

--===============1177466000916905417==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

--On Saturday, January 07, 2017 7:24 PM +0000 dpa-openldap(a)aegee.org wrote:

> Full_Name: &amp;#1044;&amp;#1080;&amp;#1083;&amp;#1103;&amp;#1085;
> &amp;#1055;&amp;#1072;&amp;#1083;&amp;#1072;&amp;#1091;&amp;#1079;&amp;#1
> 086;&amp;#1074; Version: 2.4.44
> OS: any
> URL:
> Submission from: (NULL) (141.2.134.77)
>
>
> In the manual,
> - section 8.2.5 Access Control Examples, 2nd paragraph replace "allows
> anonymous to authentication against these entries" with "authenticate";
> - section 13.2.4 Attibute Type Specification, 4th code snippet, replace
> "DESC 'common name(s) assciated with the object" with "associated";
> - section8.8.1.1 LDAP Sync Replication, last paragraph, replace "is
> defined by a general search criteria consisting of base and scope':
> remove the 'a' in front of criteria.
> - section 20 Monitoring, 3rd paragraph "This information can be access
> with ldapsearch", substitute with "accessed".

Fixed, thanks, outside of the "a general search criteria consisting of base 
and scope".  That seems correct to me.

Regards,
Quanah

--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>





--===============1177466000916905417==--


From quanah@symas.com Tue Jan 17 18:50:04 2017
From: quanah@symas.com
To: openldap-bugs@openldap.org
Subject: Re: (ITS#8563) Documentation inconsistency for syncrepl for mdb
Date: Tue, 17 Jan 2017 18:50:02 +0000
Message-ID: <E1cTYpW-000589-Sm@gauss.openldap.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3672985321587150973=="

--===============3672985321587150973==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

--On Saturday, January 07, 2017 8:13 PM +0000 dpa-openldap(a)aegee.org wrote:

> Full_Name: &amp;#1044;&amp;#1080;&amp;#1083;&amp;#1103;&amp;#1085;
> &amp;#1055;&amp;#1072;&amp;#1083;&amp;#1072;&amp;#1091;&amp;#1079;&amp;#1
> 086;&amp;#1074; Version: 2.4.44
> OS: any
> URL:
> Submission from: (NULL) (141.2.134.77)
>
>
> The manual states in section 5.2.5.8 olcSyncrepl, second last paragraph:
> "The syncrepl replication mechanism is supported by the bdb and hdb
> backends".
>
> This text above is repeated in section 6.2.3.7 syncrepl.
>
> But in section 18.1.1.2. Syncrepl Details, fourth paragraph, is written
> 'The syncrepl engine, which is a consumer-side replication engine, can
> work with any backends.  The LDAP Sync provider can be configured as an
> overlay on any backend, but works best with the back-bdb back-hdb, or
> back-mdb backends.'
>
> Can syncrepl work with any backend and does it work with bdb equally good
> as with mdb?

Fixed to mention back-mdb/mdb where appropriate.  At the time the 
documentation was written, back-mdb didn't exist.

Regards,
Quanah

--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>





--===============3672985321587150973==--


From quanah@symas.com Tue Jan 17 18:55:09 2017
From: quanah@symas.com
To: openldap-bugs@openldap.org
Subject: Re: (ITS#8560) Proxy Authorization is mentioned as a SASL mech
Date: Tue, 17 Jan 2017 18:55:07 +0000
Message-ID: <E1cTYuR-0005Fb-Ab@gauss.openldap.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1268033924164842513=="

--===============1268033924164842513==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

--On Friday, January 06, 2017 7:17 PM +0000 rick(a)openfortress.nl wrote:

> Full_Name: Rick van Rein
> Version: 2.4
> OS: N/A
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (2001:980:93a5:1:98ff:3cc8:e968:ded8)
>
>
> Hello,
>
> I found a nit in the OpenLDAP administrator's guide at
> http://www.openldap.org/doc/admin24/guide.html#SASL%20Proxy%20Authorizati
> on
>
> It mentions Proxy Authorization as a facility of SASL, something I never
> heard of.  It is defined specifically for LDAP in RFC 4370.  So the
> chapter title, and perhaps its ordering underneath SASL, are not perfect.

Hi Rick,

Thanks for the report.  However, the EXTERNAL mechanism is in fact a SASL 
mechanism, just implemented directly in OpenLDAP (vs other SASL mechanisms 
that OpenLDAP supports via Cyrus-SASL).  The location in the admin guide is 
correct.  If you read RFC 4370, Section 1 clearly notes that it is a part 
of SASL:

"The Lightweight Directory Access
   Protocol [LDAPV3] supports the use of the Simple Authentication and
   Security Layer [SASL] for authentication and for supplying an
   authorization identity distinct from the authentication identity,
   where the authorization identity applies to the whole LDAP session."

Regards,
Quanah

--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>





--===============1268033924164842513==--


From rick@openfortress.nl Tue Jan 17 20:07:48 2017
From: rick@openfortress.nl
To: openldap-bugs@openldap.org
Subject: Re: (ITS#8560) Proxy Authorization is mentioned as a SASL mech
Date: Tue, 17 Jan 2017 20:07:43 +0000
Message-ID: <E1cTa2h-0006Sg-7a@gauss.openldap.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6483193613578078924=="

--===============6483193613578078924==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Hi Quanah,

> Thanks for the report.  However, the EXTERNAL mechanism is in fact a
> SASL mechanism, just implemented directly in OpenLDAP (vs other SASL
> mechanisms that OpenLDAP supports via Cyrus-SASL).  The location in
> the admin guide is correct.

Yes, thanks, Howard also pointed that out, and I learnt.

>   If you read RFC 4370, Section 1 clearly notes that it is a part of
> SASL:
>
> "The Lightweight Directory Access
>   Protocol [LDAPV3] supports the use of the Simple Authentication and
>   Security Layer [SASL] for authentication and for supplying an
>   authorization identity distinct from the authentication identity,
>   where the authorization identity applies to the whole LDAP session."

Ehm, it doesn't actually state that Proxied Authz is part of SASL.  It
just continues to state that it is on a per-operation basis, and to me
it reads like an independent mechanism, at least as far as the protocol
is concerned.  Although it can be easily imagined that it were to share
(lots of) code with SASL EXTERNAL of course, but that would be an
implementation choice.  Or am I still not reading it correctly?

This is in fact what I was looking for; whether OpenLDAP supports this
per-operation Proxy Authz Control.  Aside from the above being properly
located, I am still missing a remark about it in the Manual.


Thanks,
 -Rick




--===============6483193613578078924==--


From michael@stroeder.com Tue Jan 17 22:02:41 2017
From: michael@stroeder.com
To: openldap-bugs@openldap.org
Subject: Re: (ITS#8560) Proxy Authorization is mentioned as a SASL mech
Date: Tue, 17 Jan 2017 22:02:40 +0000
Message-ID: <E1cTbpw-0008Sr-8r@gauss.openldap.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3734663309515499504=="

--===============3734663309515499504==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

rick(a)openfortress.nl wrote:
> This is in fact what I was looking for; whether OpenLDAP supports this
> per-operation Proxy Authz Control.

So you can try yourself. The rootdn can always do this.

The help of ldapsearch tool says:

  -e [!]<ext>[=<extparam>] general extensions (! indicates criticality)
[..]
             [!]authzid=<authzid>   (RFC 4370; "dn:<dn>" or "u:<user>")

Ciao, Michael.





--===============3734663309515499504==--


From michaelgarofalo404@yahoo.com Wed Jan 18 02:57:32 2017
From: michaelgarofalo404@yahoo.com
To: openldap-bugs@openldap.org
Subject: Re: (ITS#6104) race condition with cancel operation
Date: Wed, 18 Jan 2017 02:57:30 +0000
Message-ID: <E1cTgRG-0005JR-U5@gauss.openldap.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3619126291139287819=="

--===============3619126291139287819==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit






--===============3619126291139287819==--


From william.b.clay@acm.org Wed Jan 18 08:10:29 2017
From: william.b.clay@acm.org
To: openldap-bugs@openldap.org
Subject:
 Re: (ITS#8568) slapd SASL EXTERNAL bind getprop SSF bug; can provoke SEGFAULT
Date: Wed, 18 Jan 2017 08:10:27 +0000
Message-ID: <E1cTlK7-0002D5-E6@gauss.openldap.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2282833506353434835=="

--===============2282833506353434835==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

> So you're using TLS client cert and SASL/EXTERNAL to a hostname (also in th=
er
> server cert) but where the IP address of the hostname is directly routed th=
rough
> 127.0.0.1?

The slapd log of my same-host tests confirms they in fact used the IPv4=20
loopback address, 127.0.0.1, even though the bind URI specified the FQDN.

> Not sure but the difference is the client IP address. If the client can rea=
ch
> slapd through 127.0.0.1 the client's IP address is also 127.0.0.1 which cou=
ld
> make a difference in the SASL client handling. Anyone said hostname
> canonicalization? Does setting sasl-host <fqdn> make a difference?

The ~/.ldaprc used by the client in these tests contained "TLS_REQCERT=20
none", so a mismatch between the server's FQDN and the peer address=20
actually used would not have been detected.  Another difference would be=20
"ping-pong" memory allocation between client and server.  Even though=20
different processes, they may allocate from the same pool.  With the=20
client running on a different host in other tests, slapd would not be=20
competing with other processes in a predictable, repeatable fashion=20
(slapd SEGFAULTs were 100% repeatable for specific sequences of EXTERNAL=20
binds, but only with client and server on the same host).




--===============2282833506353434835==--


From quanah@symas.com Wed Jan 18 15:59:48 2017
From: quanah@symas.com
To: openldap-bugs@openldap.org
Subject: Re: (ITS#8544) manpage fixes
Date: Wed, 18 Jan 2017 15:59:46 +0000
Message-ID: <E1cTseI-0004XG-QN@gauss.openldap.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0286312673352660217=="

--===============0286312673352660217==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

--On Tuesday, December 13, 2016 9:10 PM +0000 
sca+openldap(a)andreasschulze.de wrote:

> Full_Name: Andreas Schulze
> Version: git
> OS: linux
> URL: ftp://ftp.openldap.org/incoming/andreas-schulze-161213.patch
> Submission from: (NULL) (2001:a60:f0b4:e502::152)
>
>
> I uploaded a patch to polish some manpages.
> All changes are suggested by debian lintian
> - phrase "allows one to" instead of "allows to"
> - some occurences of -foo have to be written as \-foo in a manpage

Thanks for the report, this has been applied with one minor change.

Regards,
Quanah



--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>





--===============0286312673352660217==--


From quanah@symas.com Wed Jan 18 16:08:34 2017
From: quanah@symas.com
To: openldap-bugs@openldap.org
Subject: Re: (ITS#8565) Clarification of the slapo-ppolicy manpage
Date: Wed, 18 Jan 2017 16:08:32 +0000
Message-ID: <E1cTsmm-0004r6-6h@gauss.openldap.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8201033797991776464=="

--===============8201033797991776464==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

--On Wednesday, January 11, 2017 4:44 PM +0000 
matthieu.cerda(a)nbs-system.com wrote:

> Full_Name: Matthieu Cerda
> Version: 2.4.40
> OS: Debian jessie
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (194.213.124.6)
>
>
> Hello !
>
> As per
> http://www.openldap.org/lists/openldap-technical/201701/msg00017.html I
> would like to submit a small improvement to the slapo-ppolicy manpage to
> clarify rootdn presence / absence implications in a ppolicy enabled setup.
>
> Here is the patch (I thing it's short enough not to justify a separate
> upload):

Thanks!  We went with something slightly different, but the rootdn 
requirement should be absolutely clear now.

Regards,
Quanah


--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>





--===============8201033797991776464==--


From elecharny@symas.com Wed Jan 18 16:47:19 2017
From: elecharny@symas.com
To: openldap-bugs@openldap.org
Subject: (ITS#8571) Added a test for pcache + ldap backen with proxyauthz
Date: Wed, 18 Jan 2017 16:47:17 +0000
Message-ID: <E1cTtOH-0005x9-Gu@gauss.openldap.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4891257005208068018=="

--===============4891257005208068018==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Full_Name: Emmanuel L.charny
Version: 2.4.45
OS: N/A
URL: ftp://ftp.openldap.org/incoming/elecharny-20170118.patch
Submission from: (NULL) (86.246.56.212)


This patch adds a unit test for a server configured with proxycache and ldap
backend, redirecting all the requests to a remote master server, which does n=
ot
accept anonymous bind). The proxycache server caches searches and binds.

The attached file is derived from OpenLDAP Software. All of the modifications=
 to
OpenLDAP Software represented in the following patch(es) were developed by
Symas. Symas has not assigned rights and/or interest in this work to any part=
y.
I, Emmanuel Lecharny, am authorized by Symas, my employer, to release this wo=
rk
under the following terms.=20

Symas 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.=20



--===============4891257005208068018==--


From william.b.clay@acm.org Thu Jan 19 08:55:11 2017
From: william.b.clay@acm.org
To: openldap-bugs@openldap.org
Subject: (ITS#8572) FOR INFO ONLY: SASL SCRAM-SHA-1 authz may fail incorrectly
Date: Thu, 19 Jan 2017 08:55:09 +0000
Message-ID: <E1cU8Uv-0003KR-GV@gauss.openldap.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4126736908600299016=="

--===============4126736908600299016==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Full_Name: Bill Clay
Version: 2.4.44
OS: Debian/GNU Linux 7.8 (Wheezy)
URL: 
Submission from: (NULL) (79.12.44.250)


Cyrus SASL 2.1.26 plugins/scram.c decode_saslname() may return a corrupt authz
name.

SASL SCRAM-SHA-1 auth with a "dn:" style authzID can return an authzID string
with trailing original (escaped) characters appended.  slapd may then
incorrectly deny the requested proxy authorization because the returned value
may fail match criteria that a correctly-decoded SASL name would pass. (There
may be other SASL SCRAM scenarios in which this flaw would produce incorrect
results.)

Cyrus SASL issue: https://github.com/cyrusimap/cyrus-sasl/issues/416



--===============4126736908600299016==--


From quanah@symas.com Thu Jan 19 15:27:22 2017
From: quanah@symas.com
To: openldap-bugs@openldap.org
Subject:
 Re: (ITS#8572) FOR INFO ONLY: SASL SCRAM-SHA-1 authz may fail incorrectly
Date: Thu, 19 Jan 2017 15:27:20 +0000
Message-ID: <E1cUEcS-000626-I2@gauss.openldap.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6623687934171442551=="

--===============6623687934171442551==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

--On Thursday, January 19, 2017 8:55 AM +0000 william.b.clay(a)acm.org wrote:

> Full_Name: Bill Clay
> Version: 2.4.44
> OS: Debian/GNU Linux 7.8 (Wheezy)
> URL:
> Submission from: (NULL) (79.12.44.250)

Hi Bill,

I appreciate that you are attempting to be helpful.  However, the ITS 
system is only for reporting bugs occuring in OpenLDAP as clearly noted on 
the ITS submission form.  If you want to provide informational updates, 
they would probably best go to the openldap-technical mailing list.

Regards,
Quanah


--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>





--===============6623687934171442551==--


From quanah@openldap.org Mon Jan 23 23:44:01 2017
From: quanah@openldap.org
To: openldap-bugs@openldap.org
Subject: (ITS#8573) ldap* tools should be able to function w/o a conf file
Date: Mon, 23 Jan 2017 23:43:59 +0000
Message-ID: <E1cVoHH-0001Oz-LS@gauss.openldap.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8808425625978403729=="

--===============8808425625978403729==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Full_Name: Quanah Gibson-Mount
Version: 2.4.44
OS: N/A
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (47.208.148.26)


Right now, it is impossible to configure the ldap* command line tools so that
they function in major circumstances w/o also having a configuration file (I.=
e.,
ldap.conf, .ldaprc, etc).  For example, the ability to use startTLS with LDAP
requires such a file so that the CA file and/or cert path for the tool can be
defined.

The "-o" option should be expanded to cover additional configuration paramete=
rs
from the conf file, as has already been done with the network timeout paramet=
er.


--===============8808425625978403729==--


From okuznik@symas.com Wed Jan 25 15:25:51 2017
From: okuznik@symas.com
To: openldap-bugs@openldap.org
Subject: (ITS#8574) bconfig support for DNs that need escaping
Date: Wed, 25 Jan 2017 15:25:50 +0000
Message-ID: <E1cWPSI-0001lo-9N@gauss.openldap.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4867419232675467812=="

--===============4867419232675467812==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Full_Name: Ondrej Kuznik
Version: master
OS:=20
URL: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170125-Deal-with-rDN-cor=
rectly.patch
Submission from: (NULL) (151.228.185.198)


When an rdn under cn=3Dconfig needs escaping, incorrect value gets passed to =
the
attribute and, if the attribute is single-value, the entry is rejected by
entry_naming_check().

Patch against master is attached.


--===============4867419232675467812==--


From simon@slevermann.de Thu Jan 26 13:36:59 2017
From: simon@slevermann.de
To: openldap-bugs@openldap.org
Subject: (ITS#8575) Argon2 Password hashing contrib module
Date: Thu, 26 Jan 2017 13:36:57 +0000
Message-ID: <E1cWkET-00036n-V3@gauss.openldap.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8675480575523072295=="

--===============8675480575523072295==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Full_Name: Simon Levermann
Version:=20
OS:=20
URL: ftp://ftp.openldap.org/incoming/simon-levermann-170126.patch
Submission from: (NULL) (2001:638:708:f002:deab:9ae4:7f07:d350)


This patch adds a password hashing module for the argon2 function to the
contrib/slapd-modules/passwd/ modules. Argon2 is a relatively new hash functi=
on
which has won the Password Hashing Competition (https://password-hashing.net)

The attached patch file is derived from OpenLDAP Software. All of the
modifications to OpenLDAP Software represented in the following patch(es) were
developed by Simon Levermann simon(a)slevermann.de. I have not assigned rights
and/or interest in this work to any party.

I, Simon Levermann, 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.



--===============8675480575523072295==--