openldap-bugs August 2019

openldap-bugs@openldap.org

18 participants
45 discussions

(ITS#9064) client tools not recognizing BINDDN from ldap.conf
by fabrice.ducos＠gmail.com 17 Aug '19

17 Aug '19

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.

1 0

Re: (ITS#9037) observing crash in mdb_cursor_put()
by vporof＠mozilla.com 15 Aug '19

15 Aug '19

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?

1 0

Re: (ITS#9037) observing crash in mdb_cursor_put()
by hyc＠symas.com 14 Aug '19

14 Aug '19

hyc(a)symas.com wrote: > vporof(a)mozilla.com wrote: >> It might be possible that even though RKV was built in debug mode, the >> backing sys crate isn't building LMDB itself this way. On a very first >> glance it looks like this is the case, always going for opt level 2: >> https://github.com/danburkert/lmdb-rs/blob/master/lmdb-sys/build.rs#L23 >> >> I'll have a closer look at the build process and see what's going on. >> >> Can you share your build process that resulted in LMDB debug functions >> being optimized away? Did you build using the fuzzer via `cargo afl`? >> Something else? > > I deleted the lmdb-rkv-sys-* directories from target/debug/build, edited > .cargo/registry/src/github.com-1ecc6299db9ec823/lmdb-rkv-sys-0.8.6/lmdb/libraries/liblmdb/mdb.c > and added #define MDB_DEBUG 3 at the top of the file, then reran the cargo build command. > > RUSTFLAGS="-Clink-arg=-fuse-ld=gold" cargo afl build -v Not really sure it's worth spending time on these fuzzer results. Basically you're feeding corrupted database files into LMDB, and it is hitting an assert because it sees that the structure is corrupted. Working as designed, in other words. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#9037) observing crash in mdb_cursor_put()
by hyc＠symas.com 14 Aug '19

14 Aug '19

vporof(a)mozilla.com wrote: > It might be possible that even though RKV was built in debug mode, the > backing sys crate isn't building LMDB itself this way. On a very first > glance it looks like this is the case, always going for opt level 2: > https://github.com/danburkert/lmdb-rs/blob/master/lmdb-sys/build.rs#L23 > > I'll have a closer look at the build process and see what's going on. > > Can you share your build process that resulted in LMDB debug functions > being optimized away? Did you build using the fuzzer via `cargo afl`? > Something else? I deleted the lmdb-rkv-sys-* directories from target/debug/build, edited .cargo/registry/src/github.com-1ecc6299db9ec823/lmdb-rkv-sys-0.8.6/lmdb/libraries/liblmdb/mdb.c and added #define MDB_DEBUG 3 at the top of the file, then reran the cargo build command. RUSTFLAGS="-Clink-arg=-fuse-ld=gold" cargo afl build -v -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#9037) observing crash in mdb_cursor_put()
by vporof＠mozilla.com 14 Aug '19

14 Aug '19

It might be possible that even though RKV was built in debug mode, the backing sys crate isn't building LMDB itself this way. On a very first glance it looks like this is the case, always going for opt level 2: https://github.com/danburkert/lmdb-rs/blob/master/lmdb-sys/build.rs#L23 I'll have a closer look at the build process and see what's going on. Can you share your build process that resulted in LMDB debug functions being optimized away? Did you build using the fuzzer via `cargo afl`? Something else?

1 0

Re: (ITS#9037) observing crash in mdb_cursor_put()
by hyc＠symas.com 14 Aug '19

14 Aug '19

vporof(a)mozilla.com wrote: > Thanks for getting back! > > The files at https://github.com/mozkeeler/rkv-fuzz/tree/trunk/crashes > are fuzzed variants of the input data seeded from the mdb input here: > They're generated when running the `american fuzzy lop` fuzzer: > http://lcamtuf.coredump.cx/afl/. It appears that rust is doing link-time optimization and deleting LMDB debug functions from the resulting binary. I'm not familiar with how the rust build system works, can we get it to stop doing this? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#9037) observing crash in mdb_cursor_put()
by vporof＠mozilla.com 14 Aug '19

14 Aug '19

Thanks for getting back! The files at https://github.com/mozkeeler/rkv-fuzz/tree/trunk/crashes are fuzzed variants of the input data seeded from the mdb input here: They're generated when running the `american fuzzy lop` fuzzer: http://lcamtuf.coredump.cx/afl/. Victor

1 0

Re: (ITS#9037) observing crash in mdb_cursor_put()
by hyc＠symas.com 14 Aug '19

14 Aug '19

vporof(a)mozilla.com wrote: > Quick update on this. > > Potentially useful to the efforts here, Dana Keeler has implemented a = > fuzzing harness for RKV (our typed Rust interface to LMDB): = > https://github.com/mozkeeler/rkv-fuzz > > We weren't able to trigger the `mdb_cursor_put` crashes reported at = > https://crash-stats.mozilla.org/signature/?signature=3Dmdb_cursor_put#repo= > rts, though we did end up finding a few others: = > https://github.com/mozkeeler/rkv-fuzz/tree/trunk/crashes What kinds of files are these, in the crashes directory? > > Howard, do any of those look familiar and potentially related? > > Victor > > > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#9037) observing crash in mdb_cursor_put()
by vporof＠mozilla.com 14 Aug '19

14 Aug '19

Quick update on this. Potentially useful to the efforts here, Dana Keeler has implemented a = fuzzing harness for RKV (our typed Rust interface to LMDB): = https://github.com/mozkeeler/rkv-fuzz We weren't able to trigger the `mdb_cursor_put` crashes reported at = https://crash-stats.mozilla.org/signature/?signature=3Dmdb_cursor_put#repo= rts, though we did end up finding a few others: = https://github.com/mozkeeler/rkv-fuzz/tree/trunk/crashes Howard, do any of those look familiar and potentially related? Victor

1 0

RE: [External] Re: (ITS#9062) Please have /build/mkdep respect TMPDIR if set
by zagarc＠oclc.org 13 Aug '19

13 Aug '19

--_000_BYAPR06MB4311BFD5C8DDA97A03E2D86AA1D20BYAPR06MB4311namp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Thank you! Chris From: Quanah Gibson-Mount <quanah(a)symas.com> Sent: Tuesday, August 13, 2019 8:06 AM To: Zagar (Contractor),Chris <zagarc(a)oclc.org>; openldap-its(a)OpenLDAP.org Subject: [External] Re: (ITS#9062) Please have /build/mkdep respect TMPDIR = if set --On Sunday, August 11, 2019 7:34 PM +0000 zagarc(a)oclc.org<mailto:zagarc@oc= lc.org> wrote: > Would you please consider changing this to: > > TMP=3D${TMPDIR-/tmp}/mkdep$$ Thanks for the report, this is fixed in OpenLDAP master. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com<http://www.symas.com>> --_000_BYAPR06MB4311BFD5C8DDA97A03E2D86AA1D20BYAPR06MB4311namp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> Thank you!<o:p></o:p> <o:p> </o:p> Chris<o:p></o:p> <o:p> </o:p> <div> <div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in = 0in 0in"> From: Quanah Gibson-Mount <quanah(a)symas.co= m> Sent: Tuesday, August 13, 2019 8:06 AM To: Zagar (Contractor),Chris <zagarc(a)oclc.org>rg>; openldap-its@O= penLDAP.org Subject: [External] Re: (ITS#9062) Please have /build/mkdep respect = TMPDIR if set<o:p></o:p> </div> </div> <o:p> </o:p> --On Sunday, August 11, 2019 7:34 PM +0000 <a href=3D"mailto:zagarc@ocl= c.org">zagarc(a)oclc.org</a> wrote: > Would you please consider changing this to: > > TMP=3D${TMPDIR-/tmp}/mkdep$$ Thanks for the report, this is fixed in OpenLDAP master. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <<a href=3D"http://www.symas.com">http://www.symas.com</a>><o:p></o:p= > </div> </body> </html> --_000_BYAPR06MB4311BFD5C8DDA97A03E2D86AA1D20BYAPR06MB4311namp_--

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs August 2019