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>
Full_Name: Fabrice Ducos
Version: 2.4.48
OS: OSX 10.14.6 Mojave
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (90.110.219.170)
I have installed OpenLDAP 2.4.48 from sources with SASL support.
For the moment, I am not using SASL.
I have created a small toy directory with a few records. I have got no problem
reading it with the local utilities (slap cat, etc). Now I am in the course of
playing with the client tools.
In my ldap.conf, I have got the following directives:
URI ldap://localhost
BASE dc=myrealm,dc=mydomain,dc=org
BINDDN cn=root,ou=users,dc=myrealm,dc=mydomain,dc=org
(root is the name I gave to my the rootdn account in slapd.conf)
The ldap.conf file has been put at the right place under
/usr/local/etc/openldap
When I perform the following command:
ldapsearch -x -W -D 'cn=root,ou=users,dc=myrealm,dc=mydomain,dc=org'
(with -x to force a simple binding)
I get the results I expect from the directory, starting from BASE (no need for a
-b option).
However, when I test:
ldapsearch -x -W
(with -D), I would expect to get the same result, the binding DN being set up
from ldap.conf BINDDN.
However, it fails:
Enter LDAP Password:
ldap_bind: Invalid credentials (49)
(this is not a problem of password, otherwise it would also fail in the first
test; I use the same password in both).
I put the example files under incoming/binddn_2019-08-18 on your ftp server.
The passwords are unencrypted in these sample files (encryption of passwords in
another topic), but it doesn't explain why the root password from slapd.conf is
recognised with -W -D and not with -W alone.
Thank for your assistance.
That's good to know. Since we're completely in the dark on how to
produce a reliable test case that exercises this crash, the hope was
that fuzzing could inch us towards a solution.
There's also the problem that we're observing these crashes on Windows 7
and x86-64 (at least for now), as evidenced by this report:
=
https://crash-stats.mozilla.org/signature/?signature=3Dmdb_cursor_put&_col=
umns=3Dplatform&_columns=3Dcpu_arch&_sort=3D-date&page=3D1#reports
Fuzzing on that platform is quite a bit more difficult since tooling is=20=
lacklustre. Furthermore, we can't really try fuzzing under WSL and=20
Windows 10, since LMDB also doesn't actually work well under WSL, due to
mmap on a 0-length file failing with ENOEXEC, also complicating things:
https://github.com/microsoft/WSL/issues/3451
I'm not clear if Robins George (OP) observed this crash on a different
platform, perhaps they can confirm?
If fuzzing isn't a worthwhile exploration avenue, any suggestions for=20
what kind of tests might exercise a crash like this?