On Wed, Aug 28, 2019 at 01:04:25AM +0000, ryan(a)openldap.org wrote:
> The GnuTLS documentation states:
>> Do not call this function from a library, or preferably from any application
>> unless really needed to.
>
> I disobeyed that guidance in commit 829027945, because I wasn't sure that
> GnuTLS's own threading support would cover all the platforms libldap does. This
> choice caused some bugs, e.g. <https://bugs.debian.org/803197> and
> <https://www.openldap.org/its/?findid=8797>.
>
> I don't know how to find out for sure whether anyone builds libldap with GnuTLS
> on a system where it lacks native mutexes. I think at this point I would rather
> fix the known broken cases, over the risk of potentially breaking a theoretical
> setup I'm not sure actually exists.
>
> Therefore: I now propose applying this change for 2.5.
A similar change (making tlso_thr_init a no-op) has been introduced in
ITS#8533 when compiling with OpenSSL 1.1.0+, so I gather it should be
fine for GnuTLS as well.
Regards,
--
Ondřej Kuzník
Senior Software Engineer
Symas Corporation http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Full_Name: Ryan Tandy
Version: master
OS: Debian
URL: https://github.com/rtandy/openldap/compare/openldap:master...rtandy:remove-…
Submission from: (NULL) (70.66.128.207)
Submitted by: ryan
The GnuTLS documentation
<https://gnutls.org/manual/html_node/Core-TLS-API.html#gnutls_005fglobal_005…>
states:
> Do not call this function from a library, or preferably from any application
unless really needed to.
I disobeyed that guidance in commit 829027945, because I wasn't sure that
GnuTLS's own threading support would cover all the platforms libldap does. This
choice caused some bugs, e.g. <https://bugs.debian.org/803197> and
<https://www.openldap.org/its/?findid=8797>.
I don't know how to find out for sure whether anyone builds libldap with GnuTLS
on a system where it lacks native mutexes. I think at this point I would rather
fix the known broken cases, over the risk of potentially breaking a theoretical
setup I'm not sure actually exists.
Therefore: I now propose applying this change for 2.5.
I made this change as a distro patch in Debian 10 (buster), and no Debian or
Ubuntu users have reported any regressions so far. I also did some local testing
with slapd and slapd-mtread on the GnuTLS versions shipped in the last few
releases of Debian.
I have not tested any non-Linux platforms yet. For completeness, I should
probably try this on at least FreeBSD and Solaris. I kind of assume GnuTLS
system mutexes are going to work anywhere LMDB already does.
Rationale for the change, from the commit message:
Since GnuTLS moved to implicit initialization on library load, calling this
function deinitializes GnuTLS and then re-initializes it.
When GnuTLS uses /dev/urandom as an entropy source (getrandom() not available,
or older versions of GnuTLS), and the application closed all file descriptors at
startup, this could result in GnuTLS opening /dev/urandom over one of the
application's file descriptors when re-initialized.
Additionally, the custom mutex functions are never reset, so if libldap is
unloaded (for example via dlclose()) after calling this, its code may be
unmapped and the application could crash when GnuTLS calls the mutex functions.
On typical systems, GnuTLS system mutexes are probably the same as what libldap
uses anyway.
IPR:
The attached patch file is derived from OpenLDAP Software. All of the
modifications to OpenLDAP Software represented in the following patch were
developed by Ryan Tandy <ryan(a)nardis.ca>. I have not assigned rights and/or
interest in this work to any party.
I, Ryan Tandy, 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.
Full_Name: Howard Chu
Version: 0.9.24
OS:
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (80.233.39.186)
Submitted by: hyc
When reloading a printable dump (from mdb_dump -p), actual backslashes in the
input
(represented as '\\') will be corrupted. This has been broken since mdb_load was
written in 2004.
bremer(a)univention.de wrote:
> Full_Name: Julia Bremer
> Version: 2.4.45
> OS: debian / UCS 4.4
> URL: http://updates.software-univention.de/download/temp/openldap/fix-syntax-eva…
> Submission from: (NULL) (82.198.197.8)
>
>
> Trying to set the value of the attribute preferredDeliveryMethod to a sequence
> of items, separated by " $ ", e.g "telephone $ videotex" fails with
>
> ldap_modify: Invalid syntax (21)
> additional info: preferredDeliveryMethod: value #0 invalid per syntax
>
> even though the syntax is correct according to the RFC4517
> (Syntax 1.3.6.1.4.1.1466.115.121.1.14).
> https://tools.ietf.org/html/rfc4517#section-3.3.5
>
> This is due to an error in the method deliveryMethodValidate in
> servers/slapd/schema_init.c which causes the function to check the string
> backwards after a space character occurs.
> The attached patch fixes this, so that the syntax is validated correctly.
Thanks for the report, committed to master. Looks like this code has never been used
since Kurt wrote it in 2004. I've tested it locally now but would ask whether you have
time to also add a check into the test suite. Thanks.
>
>
> Univention 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.
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Full_Name: Julia Bremer
Version: 2.4.45
OS: debian / UCS 4.4
URL: http://updates.software-univention.de/download/temp/openldap/fix-syntax-eva…
Submission from: (NULL) (82.198.197.8)
Trying to set the value of the attribute preferredDeliveryMethod to a sequence
of items, separated by " $ ", e.g "telephone $ videotex" fails with
ldap_modify: Invalid syntax (21)
additional info: preferredDeliveryMethod: value #0 invalid per syntax
even though the syntax is correct according to the RFC4517
(Syntax 1.3.6.1.4.1.1466.115.121.1.14).
https://tools.ietf.org/html/rfc4517#section-3.3.5
This is due to an error in the method deliveryMethodValidate in
servers/slapd/schema_init.c which causes the function to check the string
backwards after a space character occurs.
The attached patch fixes this, so that the syntax is validated correctly.
Univention 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.
--On Thursday, August 22, 2019 12:08 PM +0000 juanma171(a)yahoo.es wrote:
> Full_Name: JuanMa
> Version: 2.4.45
> OS: Ubuntu 18.04.2
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (92.176.151.51)
>
>
> Afeter creating custom attrs, I can see in ldap browser, but after
> restart sldap daemon, custom attrs are missing (sorry, bad english)
> OLC mode and mdb database
Hello,
That is not the correct way to modify the schema or add new attributes.
Please use the openldap-technical(a)openldap.org list for help. This ITS
will be closed.
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
Full_Name: Quanah Gibson-Mount
Version: 2.4.48
OS: N/A
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (47.208.128.44)
The slapo-ppolicy(5) man page has this statement in the description of
pwdGraceUseTime:
If too many grace logins have been used (please refer to the pwdGraceLoginLimit
password policy attribute),
However, there is no such attribute as "pwdGraceLoginLimit". It is instead
pwdGraceAuthnLimit
--On Sunday, August 18, 2019 12:19 AM +0000 fabrice.ducos(a)gmail.com wrote:
> In my ldap.conf
The ldap.conf(5) man page clearly states that the BINDDN variable is a USER
ONLY option. That means it will only be honored if it appears in the
~user/.ldaprc file.
This ITS will be closed.
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>