November 2015 - openldap-bugs

Re: (ITS#8267) contributing a new overlay unicodepw

by ingo.voss＠gmail.com

2015-10-25 9:28 GMT+01:00 Howard Chu <hyc(a)symas.com>: > Ingo Voss wrote: >> >> >> >> Am 17.10.2015 um 20:58 schrieb Howard Chu: >>> >>> ingo.voss(a)gmail.com wrote: >>>> >>>> Full_Name: Ingo Voss >>>> Version: >>>> OS: >>>> URL: ftp://ftp.openldap.org/incoming/contrib-slapd-modules-unicodepw.tar >>>> Submission from: (NULL) (78.53.86.212) >>>> >>>> >>>> Hello, >>>> >>>> I wrote a small overlay, that restricts all LDAP modification requests, >>>> so >>>> that >>>> only password changes for MS unicodePwd are possible. >>>> All other LDAP requests will not be observed. >>>> If someone needs a read-only proxy (in a e.g. dmz) for an MS Active >>>> Directory, >>>> but password changes must be possible, then unicodepw is the right >>>> overlay. >>>> For more informations, a manual page is included. >>> >>> >>> If you want a read-only proxy, shouldn't this overlay also intercept and >>> deny all Add/Delete/ModDN requests? >>> >> >> Yes, you are right! But such overlay (denyop) exist already and it is >> working >> well. >> The manual page for unicodepw refers to denyop and describes the complete >> configuration in detail. > > > OK. > > This code is full of C++ comments. OpenLDAP uses C comments only. > > This code is full of SPACEs for indentation. OpenLDAP uses TAB characters > for indentation, with 4-column tab stops. OK, I'll change that. > > Your debug messages are using STATS debug level. STATS is reserved for LDAP > operation/parameter logging only and is the default level. Code should be > silent at the default level unless major errors have occurred. Please can you guide me what log level should be used for such security related messages? The messages are only logged, if a password is changed. (Normally, password changes are very seldom and makes low noise.) Thanks Ingo

7 years, 11 months

1
0
0 / 0

Re: (ITS#8301) signed/unsigned confusion in ber_get_next()

by ryan＠nardis.ca

On Thu, Nov 05, 2015 at 12:12:26AM +0000, ondra(a)mistotebe.net wrote: >Hi, the following will assert in liblber on i386 (and it should be possible to >craft a similar one for 64bit, I think): > >echo 'CoSSoJKSCg==' | base64 -d | ~/code/openldap/libraries/liblber/etest . ITYM dtest? slapd's sane default setting for sb_max_incoming appears to mitigate most of the potential security impact of this one.

7 years, 11 months

1
0
0 / 0

(ITS#8301) signed/unsigned confusion in ber_get_next()

by ondra＠mistotebe.net

Full_Name: Ond&#345;ej Kuzn.k Version: re24 OS: Linux i386 URL: Submission from: (NULL) (86.166.135.137) Hi, the following will assert in liblber on i386 (and it should be possible to craft a similar one for 64bit, I think): echo 'CoSSoJKSCg==' | base64 -d | ~/code/openldap/libraries/liblber/etest . My first reaction was that it encodes a length that, while still not enough to overflow the address space, will have the highest bit set and is interpreted as negative when saved into to_go in io.c:658, triggering the assert. However ber_get_next is more complex than that and I can't read BER yet.

7 years, 11 months

1
0
0 / 0

Re: (ITS#8300) LMDB mdb_cursor_del data loss

by hyc＠symas.com

malyn(a)strangeGizmo.com wrote: > Full_Name: Michael Alyn Miller > Version: Git head > OS: Windows 8.1 x64, NixOS 14.12 x64 > URL: ftp://ftp.openldap.org/incoming/michaelalynmiller-151104.c > Submission from: (NULL) (96.251.78.237) > > > Another issue similar to ITS#8264 and ITS#8299, but this time using > mdb_cursor_del inside of the cursor causes corruption. mdb_del causes > corruption as well, but this is the first time that I have seen mdb_cursor_del > do the wrong thing. > > In this case, mdb_cursor_del incorrectly removes one extra key (a key > prefixed with 0c000000000000003a...) in addition to correctly removing all of > the keys that begin with 0d000000000000003a. > > mdb_del does not remove that extra key, but instead fails to remove two > 0d000000000000003a keys that should have been removed. > > I am not sure if these are two different bugs or if they are caused by the same > underlying issue. Similar reason, two different mistakes. Fixed now in git. > > mdb_cursor_del performs correctly on subsequent runs if you do *not* remove the > database between tests, whereas mdb_del continues to fail, but stabilizes on a > different set of results after the first run. > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

7 years, 11 months

1
0
0 / 0

RE: (ITS#8299) LMDB mdb_del data loss when used in a cursor (new repro)

by malyn＠strangegizmo.com

> >> I have a new repro of an ITS#8264-like situation, but with different > >> input data and with slightly different results. Note that ITS#8264 > >> was fixed with the dataset provided in that bug; this is a different > >> dataset and produces different results. > >> > >> The referenced test runs twice: once with mdb_cursor_del and once with > mdb_del. > >> Just like before, mdb_cursor_del performs correctly whereas mdb_del > >> corrupts the database. In this case, mdb_del incorrectly removes one > >> extra key (a key prefixed with 04000000000000003a...), and > >> incorrectly leaves 21 keys in place that should have been deleted > >> (those keys begin with 05000000000000003a...). > >> This last item is the primary difference between these two bugs. > >> > >> Unlike ITS#8264, you do not need to remove the database in between > >> test runs in order to repro this issue, although the results are > >> still incorrect and will eventually cause a bus error. > > > > Thanks again for the excellent bug reports. Fixed now in git. >=20 > I should also note that this is not a sensible use case. mdb_del has to > construct a cursor to perform its work; if you already have a cursor open= you > should just use mdb_cursor_del. mdb_del is meant for one-shot use and is > much slower than mdb_cursor_del when used in an iteration. Thanks for this information. I will make the change to use mdb_cursor_del = when possible. There are a couple of circumstances where I do not currentl= y have access to the cursor though and will need to use mdb_del (or mdb_put= , for updates) inside of the cursor. I will look into passing the cursor u= p to my higher-level API callers though... Note that I just reported ITS#8300, which was found after making the switch= to mdb_cursor_del (and after applying the fix for ITS#8299). Thanks, Michael Alyn Miller

7 years, 11 months

1
0
0 / 0

(ITS#8300) LMDB mdb_cursor_del data loss

by malyn＠strangeGizmo.com

Full_Name: Michael Alyn Miller Version: Git head OS: Windows 8.1 x64, NixOS 14.12 x64 URL: ftp://ftp.openldap.org/incoming/michaelalynmiller-151104.c Submission from: (NULL) (96.251.78.237) Another issue similar to ITS#8264 and ITS#8299, but this time using mdb_cursor_del inside of the cursor causes corruption. mdb_del causes corruption as well, but this is the first time that I have seen mdb_cursor_del do the wrong thing. In this case, mdb_cursor_del incorrectly removes one extra key (a key prefixed with 0c000000000000003a...) in addition to correctly removing all of the keys that begin with 0d000000000000003a. mdb_del does not remove that extra key, but instead fails to remove two 0d000000000000003a keys that should have been removed. I am not sure if these are two different bugs or if they are caused by the same underlying issue. mdb_cursor_del performs correctly on subsequent runs if you do *not* remove the database between tests, whereas mdb_del continues to fail, but stabilizes on a different set of results after the first run.

7 years, 11 months

1
0
0 / 0

Re: (ITS#8299) LMDB mdb_del data loss when used in a cursor (new repro)

by hyc＠symas.com

Howard Chu wrote: > malyn(a)strangeGizmo.com wrote: >> Full_Name: Michael Alyn Miller >> Version: Git head >> OS: Windows 8.1 x64, NixOS 14.12 x64 >> URL: ftp://ftp.openldap.org/incoming/michaelalynmiller-151103.c >> Submission from: (NULL) (96.251.78.237) >> >> >> I have a new repro of an ITS#8264-like situation, but with different input data >> and with slightly different results. Note that ITS#8264 was fixed with the >> dataset provided in that bug; this is a different dataset and produces >> different >> results. >> >> The referenced test runs twice: once with mdb_cursor_del and once with mdb_del. >> Just like before, mdb_cursor_del performs correctly whereas mdb_del corrupts >> the >> database. In this case, mdb_del incorrectly removes one extra key (a key >> prefixed with 04000000000000003a...), and incorrectly leaves 21 keys in place >> that should have been deleted (those keys begin with 05000000000000003a...). >> This last item is the primary difference between these two bugs. >> >> Unlike ITS#8264, you do not need to remove the database in between test runs in >> order to repro this issue, although the results are still incorrect and will >> eventually cause a bus error. > > Thanks again for the excellent bug reports. Fixed now in git. I should also note that this is not a sensible use case. mdb_del has to construct a cursor to perform its work; if you already have a cursor open you should just use mdb_cursor_del. mdb_del is meant for one-shot use and is much slower than mdb_cursor_del when used in an iteration. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

7 years, 11 months

1
0
0 / 0

Re: (ITS#8299) LMDB mdb_del data loss when used in a cursor (new repro)

by hyc＠symas.com

malyn(a)strangeGizmo.com wrote: > Full_Name: Michael Alyn Miller > Version: Git head > OS: Windows 8.1 x64, NixOS 14.12 x64 > URL: ftp://ftp.openldap.org/incoming/michaelalynmiller-151103.c > Submission from: (NULL) (96.251.78.237) > > > I have a new repro of an ITS#8264-like situation, but with different input data > and with slightly different results. Note that ITS#8264 was fixed with the > dataset provided in that bug; this is a different dataset and produces different > results. > > The referenced test runs twice: once with mdb_cursor_del and once with mdb_del. > Just like before, mdb_cursor_del performs correctly whereas mdb_del corrupts the > database. In this case, mdb_del incorrectly removes one extra key (a key > prefixed with 04000000000000003a...), and incorrectly leaves 21 keys in place > that should have been deleted (those keys begin with 05000000000000003a...). > This last item is the primary difference between these two bugs. > > Unlike ITS#8264, you do not need to remove the database in between test runs in > order to repro this issue, although the results are still incorrect and will > eventually cause a bus error. Thanks again for the excellent bug reports. 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/

7 years, 11 months

1
0
0 / 0

(ITS#8299) LMDB mdb_del data loss when used in a cursor (new repro)

by malyn＠strangeGizmo.com

Full_Name: Michael Alyn Miller Version: Git head OS: Windows 8.1 x64, NixOS 14.12 x64 URL: ftp://ftp.openldap.org/incoming/michaelalynmiller-151103.c Submission from: (NULL) (96.251.78.237) I have a new repro of an ITS#8264-like situation, but with different input data and with slightly different results. Note that ITS#8264 was fixed with the dataset provided in that bug; this is a different dataset and produces different results. The referenced test runs twice: once with mdb_cursor_del and once with mdb_del. Just like before, mdb_cursor_del performs correctly whereas mdb_del corrupts the database. In this case, mdb_del incorrectly removes one extra key (a key prefixed with 04000000000000003a...), and incorrectly leaves 21 keys in place that should have been deleted (those keys begin with 05000000000000003a...). This last item is the primary difference between these two bugs. Unlike ITS#8264, you do not need to remove the database in between test runs in order to repro this issue, although the results are still incorrect and will eventually cause a bus error.

7 years, 11 months

1
0
0 / 0

Re: (ITS#8296) slapd suddenly crash when using syncprov

by maurizio.lattuada＠gmail.com

Hello Quanah, unfortunately I cannot send here the complete and precise schema, is used by our internal proprietary applications. Anyway, it can be described as: * dc=directory ** ou=person ** ou=organization ** ou=relationship "ou=person" has "objectClass=inetOrgPerson" and an identifier (yeah, clearly other fields like first name, last name, isActive, phone number, address and so on) "ou=organization" has an identifier plus the other "common" fields (name, address...) "ou=relationship" has "objectClass=groupOfNames" and is used to describe: * relationships between persons and organizations ("a person belongs to one or more organization", that is an "organization has these persons as members") * relationships between organizations (e.g. "org_1_a is a sub-organization of the main organization org_1", that is "org_1 has org_1_a as member"). So, considering the schema I described in my previous email: Test-bench_application --> spring_http_invoker --> Server_side_app ---> data_for_db_2 ---> LDAP ---> data_from_db_2 ---> App_in_syncprov_with_ldap the "Server_side_app" creates in sequence: * one unique organization (let me call it simply "org_p", it has no sub-organization) * about 19500 persons by doing a loop as: ** create one person ** create the related entry in "ou=relationship" to describe "person x belongs to org_p" Meanwhile this procedure is done, the synchronization via syncprov is running to keep in sync the LDAP database 2 and "App_in_syncprov_with_ldap". Hope it helps. thanks for the feedback. 2015-10-30 19:06 GMT+01:00 Quanah Gibson-Mount <quanah(a)zimbra.com>: > --On Friday, October 30, 2015 10:35 AM +0100 Maurizio Lattuada > <maurizio.lattuada(a)gmail.com> wrote: > >> Hello Quanah, >> >> I added the syncprov overlay to the 1st database, but is neither used >> by our application (rather than by another off-the-shelf application) >> nor replicated as is for the 2nd database. >> For your 2nd request, unfortunately I'm not able to test it, since >> between the LDAP and my test-bench application there is another server >> side application: > > > Ok. Is it possible to provide the custom schema you are using, and an > example of a user entry you are loading, so I can template it? I'd like to > see if I can reproduce the problem. > > Thanks. > > > --Quanah > > -- > > Quanah Gibson-Mount > Platform Architect > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration -- Maurizio Lattuada

7 years, 11 months

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs November 2015