openldap-bugs April 2016

openldap-bugs@openldap.org

19 participants
66 discussions

(ITS#8406) LMDB: Assertion 'mc->mc_flags & C_INITIALIZED' with MDB_NEXT after mdb_cursor_del
by akyrtzi＠gmail.com 18 Apr '16

18 Apr '16

Full_Name: Argyrios Kyrtzidis Version: LMDB master OS: OSX URL: Submission from: (NULL) (2601:646:8900:3c89:b9af:5cb2:7292:8835) With latest lmdb source (github mirror: 8fff90db7ed1e650395f39f9e8b22673aa74aa2b), there is an assertion hit when deleting the cursor and then doing mdb_cursor_get(MDB_NEXT) and 'entering' DUPSORT items. To demonstrate see below diff which modifies mtest3.c. When run you see this: mdb.c:6424: Assertion 'mc->mc_flags & C_INITIALIZED' failed in mdb_cursor_next() ==== diff --git a/libraries/liblmdb/mtest3.c b/libraries/liblmdb/mtest3.c dedex 73ee6e2..a9eb011 100644 --- a/libraries/liblmdb/mtest3.c +++ b/libraries/liblmdb/mtest3.c @@ -62,6 +62,19 @@ int main(int argc,char * argv[]) data.mv_size = sizeof(sval); data.mv_data = sval; + memset(sval, sizeof(sval), 0); + memset(kval, sizeof(kval), 0); + kval[0] = 1; + mdb_put(txn, dbi, &key, &data, 0); + kval[0] = 2; + mdb_put(txn, dbi, &key, &data, 0); + sval[0] = 1; + mdb_put(txn, dbi, &key, &data, 0); + E(mdb_cursor_open(txn, dbi, &cursor)); + E(mdb_cursor_get(cursor, &key, &data, MDB_NEXT)); + E(mdb_cursor_del(cursor, 0)); + E(mdb_cursor_get(cursor, &key, &data, MDB_NEXT)); // Assertion hit. + printf("Adding %d values\n", count); for (i=0;i<count;i++) { if (!(i & 0x0f))

1 0

(ITS#8404) Fix for an assertion failure when olcDbRewrite is modified on a meta or asyncmeta database
by nivanova＠symas.com 14 Apr '16

14 Apr '16

Full_Name: Nadezhda Ivanova Version: 2.5 OS: Ubuntu 14.04 URL: ftp://ftp.openldap.org/incoming/nadezhda-ivanova-160414.patch Submission from: (NULL) (78.83.54.234) The problem was reproduced when attempting to modify the dynamic configuration of meta and asyncmeta rewrite engine. On a meta database that has rewrite enabled and some rewrite rules configured, execute ldapmodify with the following LDIF: dn: olcMetaSub={0}uri,olcDatabase={1}meta,cn=config replace: olcDbRewrite olcDbRewrite: rewriteEngine "off"

1 0

RE: (ITS#8402) indexing issue
by escriba＠cells.es 13 Apr '16

13 Apr '16

Mail system message that raised the alarm: Reporting-MTA: dns; mail01.xxxx.xx X-Postfix-Queue-ID: 24C5526003F X-Postfix-Sender: rfc822; xxxxx at xxx .xy Arrival-Date: Wed, 13 Apr 2016 16:30:34 +0200 (CEST) Final-Recipient: rfc822; xxxxx @ xxx .xy Original-Recipient: rfc822; xxxxxx at xxx .xy Action: failed Status: 5.1.1 Remote-MTA: dns; mail02.xxxx.xx Diagnostic-Code: smtp; 550 5.1.1 <xxxxxxx at xxx .xy >: Recipient address rejected: User unknown in local recipient table >From my point of view indexing, even if not needed, may never do the queries fail, isn't it? But seems something weird happened. Regards.

1 0

(ITS#8402) indexing issue
by escriba＠cells.es 13 Apr '16

13 Apr '16

Full_Name: Ramon Escriba Version: openldap2-2.4.23-11.3.1.x86_64 OS: openSUSE 11.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.89.248.48) Hi, well, is not a bug, maybe an strange interaction between openldap & postfix +saslauth. I detected those logs: Apr 13 16:40:42 <myldap> slapd[23125]: <= bdb_equality_candidates: (mailhost) not indexed So I thought, indexing may solve it. "mailhost" user attribute may only have 2 values, mail01 or mail02. Yes, maybe is not the best thing to index, but I did a try. So I added index mailhost eq in slapd.conf. Slaptest ok. Rcldap stop; slapindex; rcldap start. But then, one mail system began to fail. I comment out the index, restarted daemons & works fine again. Saslauthd.conf query: ldap_filter: ( &(uid=%u) (mailhost=mail02) (mActive=1) (objectClass=CourierMailAlias)) Postfix queries: query_filter = ( &(mail=%s) (mailhost=mail02) (mActive=1) (objectClass=CourierMailAlias)) query_filter = ( &(maildrop=%s) (mailhost=mail02) (mActive=1) (objectClass=CourierMailAlias)) Is just for curiosity. What do you thing it may happen? Why indexing mailhost makes the query fail?? I think I miss something important. Regards.

1 0

Re: (ITS#8401) mdb_env_stat crashes if env is not open
by hyc＠symas.com 13 Apr '16

13 Apr '16

gahr(a)gahr.ch wrote: > Full_Name: Pietro Cerutti > Version: lmdb 0.9.18 > OS: FreeBSD > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (69.191.176.32) > > > mdb_env_stat crashes is the env was created but not opened. This happens because > mdb_env_stat calls mdb_env_pick_meta, which doesn't check whether the two pages > are NULL before dereferencing them. > > Please note that there is no mention of the fact that the env must have been > opened before calling mdb_env_stat in the documentation [1]. You're not reading carefully. http://symas.com/mdb/doc/group__mdb.html#gaad6be3d8dcd4ea01f8df436f41d158d4 "Before the handle may be used, it must be opened using mdb_env_open()." 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/

1 0

(ITS#8401) mdb_env_stat crashes if env is not open
by gahr＠gahr.ch 13 Apr '16

13 Apr '16

Full_Name: Pietro Cerutti Version: lmdb 0.9.18 OS: FreeBSD URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (69.191.176.32) mdb_env_stat crashes is the env was created but not opened. This happens because mdb_env_stat calls mdb_env_pick_meta, which doesn't check whether the two pages are NULL before dereferencing them. Please note that there is no mention of the fact that the env must have been opened before calling mdb_env_stat in the documentation [1]. The proposed patch is to check whether the environment is active before getting the most recent page: --- mdb.c.orig 2016-04-13 10:00:30.084676000 +0000 +"B2B mdb.c 2016-04-13 10:07:32.064085000 +0000 @@ -9432,7 +9432,7 @@ { MDB_meta *meta; - if (env == NULL || arg == NULL) + if (env == NULL || !(env->me_flags & MDB_ENV_ACTIVE) || arg == NULL) return EINVAL; meta = mdb_env_pick_meta(env); [1] http://symas.com/mdb/doc/group__mdb.html#gaf881dca452050efbd434cd16e4bae255

1 0

Re: (ITS#8400) contiguous spaces in middle of DN - translucent overlay proxy
by dsullivan2＠bsd.uchicago.edu 12 Apr '16

12 Apr '16

VGhhbmsgeW91IGZvciB0YWtpbmcgdGhlIHRpbWUgdG8gcmVwbHkgdG8gbWUgKEkgYXNzdW1lIHlv dSBhcmUgdmVyeSBidXN5KS4gIEkgYXBvbG9naXplIGZvciB0aGlzLCBJIHdvdWxkbuKAmXQgcmVw b3J0IHRoaXMgYXMgYSBidWcgdW5sZXNzIEkgdGhvdWdodCBpdCByZWFsbHkgd2FzLg0KDQpEYW4g U3VsbGl2YW4NCg0KPiBPbiBBcHIgMTEsIDIwMTYsIGF0IDc6MTIgUE0sIEhvd2FyZCBDaHUgPGh5 Y0BzeW1hcy5jb20+IHdyb3RlOg0KPiANCj4gZHN1bGxpdmFuMkBic2QudWNoaWNhZ28uZWR1IHdy b3RlOg0KPj4gRnVsbF9OYW1lOiBEYW4gU3VsbGl2YW4NCj4+IFZlcnNpb246ICAyLjQuNDAtNy5l bDZfNw0KPj4gT1M6IFJIRUwNCj4+IFVSTDogZnRwOi8vZnRwLm9wZW5sZGFwLm9yZy9pbmNvbWlu Zy8NCj4+IFN1Ym1pc3Npb24gZnJvbTogKE5VTEwpICgyMDUuMjA4LjEyMi4yMzApDQo+PiANCj4+ IA0KPj4gSGksDQo+PiANCj4+IEkgYW0gcmVwb3J0aW5nIHdoYXQgSSBiZWxpZXZlIHRvIGJlIGEg YnVnIGluIHRoZSB0cmFuc2x1Y2VudCBvdmVybGF5IHByb3h5LiAgSXQNCj4+IGFwcGVhcnMgdGhh dCB0d28gY29udGlndW91cyBub24tZXNjYXBlZCBzcGFjZXMgaW4gdGhlIG1pZGRsZSBvZiBhIERO IHdpbGwgZ2V0DQo+PiBzZW50IHRvIHRoZSByZW1vdGUgc2VydmVyIGFzIGEgc2luZ2xlIHNwYWNl LiAgRm9yIGV4YW1wbGUsIGlmIEkgaGF2ZSB0aGUNCj4+IGZvbGxvd2luZyByZWNvcmQgYmVpbmcg ZHVtcGVkIGZyb20gdGhlIGxvY2FsIGRhdGFiYXNlIHVzaW5nIHNsYXBjYXQ6DQo+IA0KPiBUaGlz IGlzIG5vdCBhIGJ1Zy4gQXMgc3BlY2lmaWVkIGluIFguNTIwLCBtdWx0aXBsZSBjb25zZWN1dGl2 ZSBzcGFjZXMgYXJlIGluc2lnbmlmaWNhbnQuDQo+IA0KPiBDbG9zaW5nIHRoaXMgSVRTLg0KPiAN Cj4+IA0KPj4gZG46IGNuPWZvb1wyQyBiYXIgIFtCU0RdIC0gSEdELG91PWdlbmVyYWwNCj4+IGFj Y291bnRzLG91PWFjY291bnRzLG91PWhnZCxkYz1zb21lZG9tYWluLGRjPXVjaGljYWdvLGRjPWVk dQ0KPj4gZ2lkTnVtYmVyOiAzMzk3OTI5MjINCj4+IHVpZE51bWJlcjozOTM5Nzk4NTE2DQo+PiBo b21lRGlyZWN0b3J5OiAvaG9tZS9mYmFyDQo+PiBzQU1BY2NvdW50TmFtZTogZmJhcg0KPj4gb2Jq ZWN0Q2xhc3M6IHBlcnNvbg0KPj4gDQo+PiBUaGVyZSBhcmUgdHdvIHNwYWNlcyBiZXR3ZWVuIGJh ciBhbmQgW0JTRF0uICBJZiBJIHF1ZXJ5IExEQVAgZm9yIHVpZE51bWJlciAodmlhDQo+PiB0cmFu c2x1Y2VudCBsb2NhbCksIHRoZSBzZWFyY2ggRE4gdGhhdCBpcyBwYXNzZWQgdG8gdGhlIHJlbW90 ZSBzZXJ2ZXIgb25seSBoYXMNCj4+IG9uZSBzcGFjZSBpbiBpdC4gIEJhc2VkIG9uIG15IHVuZGVy c3RhbmRpbmcgaXQgaXMgYWNjZXB0YWJsZSB0byBoYXZlIGFueSBudW1iZXINCj4+IG9mIHNwYWNl cyBpbiBhIEROIHdpdGhvdXQgZXNjYXBpbmcgdGhlbSAoYXMgbG9uZyBhcyB0aGV5IGFyZSBub3Qg dGhlIGZpcnN0IG9yDQo+PiB0aGUgbGFzdCBjaGFyYWN0ZXJzIGluIHRoZSBmaWVsZCkuICBJIHZl cmlmaWVkIHRoYXQgb25seSBhIHNpbmdsZSBzcGFjZSBpcyBiZWluZw0KPj4gc2VudCB0byB0aGUg cmVtb3RlIHNlcnZlciBieSBkb2luZyBhIHBhY2tldCBjYXB0dXJlIGFuZCBsb29raW5nIGF0IHRo ZSBhY3R1YWwNCj4+IExEQVAgcXVlcnkgYmVpbmcgc2VudC4NCj4+IA0KPj4gSWYgaXQgd291bGQg aGVscCB0byBwcm92aWRlIGNvbmZpZ3VyYXRpb24sIGFkZGl0aW9uYWwgbG9ncywgb3IgYSBwYWNr ZXQgY2FwdHVyZQ0KPj4gcGxlYXNlIGFkdmlzZSBhbmQgSSBjYW4gcHJvdmlkZSB0aGlzLg0KPj4g DQo+PiBJIGJlbGlldmUgbXkgb3ZlcmxheSBwcm94eSB3b3JrcyBmaW5lIG90aGVyd2lzZS4NCj4+ IA0KPj4gRGFuDQo+PiANCj4+IA0KPiANCj4gDQo+IC0tIA0KPiAgLS0gSG93YXJkIENodQ0KPiAg Q1RPLCBTeW1hcyBDb3JwLiAgICAgICAgICAgaHR0cDovL3d3dy5zeW1hcy5jb20NCj4gIERpcmVj dG9yLCBIaWdobGFuZCBTdW4gICAgIGh0dHA6Ly9oaWdobGFuZHN1bi5jb20vaHljLw0KPiAgQ2hp ZWYgQXJjaGl0ZWN0LCBPcGVuTERBUCAgaHR0cDovL3d3dy5vcGVubGRhcC5vcmcvcHJvamVjdC8N Cg0KCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqClRoaXMgZS1tYWlsIGlzIGludGVuZGVkIG9ubHkg Zm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoCml0IGlzIGFk ZHJlc3NlZCBhbmQgbWF5IGNvbnRhaW4gaW5mb3JtYXRpb24gdGhhdCBpcyBwcml2aWxlZ2VkIGFu ZCBjb25maWRlbnRpYWwuCklmIHRoZSByZWFkZXIgb2YgdGhpcyBlLW1haWwgbWVzc2FnZSBpcyBu b3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSAKaGVyZWJ5IG5vdGlmaWVkIHRoYXQg YW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiBvciBjb3B5aW5nIG9mIHRoaXMKY29tbXVu aWNhdGlvbiBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGUtbWFpbCBp biBlcnJvciwgcGxlYXNlIApub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVzdHJveSBhbGwgY29waWVz IG9mIHRoZSB0cmFuc21pdHRhbC4gCgpUaGFuayB5b3UKVW5pdmVyc2l0eSBvZiBDaGljYWdvIE1l ZGljaW5lIGFuZCBCaW9sb2dpY2FsIFNjaWVuY2VzIAoqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgo=

1 0

Re: (ITS#8400) contiguous spaces in middle of DN - translucent overlay proxy
by hyc＠symas.com 11 Apr '16

11 Apr '16

dsullivan2(a)bsd.uchicago.edu wrote: > Full_Name: Dan Sullivan > Version: 2.4.40-7.el6_7 > OS: RHEL > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (205.208.122.230) > > > Hi, > > I am reporting what I believe to be a bug in the translucent overlay proxy. It > appears that two contiguous non-escaped spaces in the middle of a DN will get > sent to the remote server as a single space. For example, if I have the > following record being dumped from the local database using slapcat: This is not a bug. As specified in X.520, multiple consecutive spaces are insignificant. Closing this ITS. > > dn: cn=foo\2C bar [BSD] - HGD,ou=general > accounts,ou=accounts,ou=hgd,dc=somedomain,dc=uchicago,dc=edu > gidNumber: 339792922 > uidNumber:3939798516 > homeDirectory: /home/fbar > sAMAccountName: fbar > objectClass: person > > There are two spaces between bar and [BSD]. If I query LDAP for uidNumber (via > translucent local), the search DN that is passed to the remote server only has > one space in it. Based on my understanding it is acceptable to have any number > of spaces in a DN without escaping them (as long as they are not the first or > the last characters in the field). I verified that only a single space is being > sent to the remote server by doing a packet capture and looking at the actual > LDAP query being sent. > > If it would help to provide configuration, additional logs, or a packet capture > please advise and I can provide this. > > I believe my overlay proxy works fine otherwise. > > Dan > > -- -- 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

(ITS#8400) contiguous spaces in middle of DN - translucent overlay proxy
by dsullivan2＠bsd.uchicago.edu 11 Apr '16

11 Apr '16

Full_Name: Dan Sullivan Version: 2.4.40-7.el6_7 OS: RHEL URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (205.208.122.230) Hi, I am reporting what I believe to be a bug in the translucent overlay proxy. It appears that two contiguous non-escaped spaces in the middle of a DN will get sent to the remote server as a single space. For example, if I have the following record being dumped from the local database using slapcat: dn: cn=foo\2C bar [BSD] - HGD,ou=general accounts,ou=accounts,ou=hgd,dc=somedomain,dc=uchicago,dc=edu gidNumber: 339792922 uidNumber:3939798516 homeDirectory: /home/fbar sAMAccountName: fbar objectClass: person There are two spaces between bar and [BSD]. If I query LDAP for uidNumber (via translucent local), the search DN that is passed to the remote server only has one space in it. Based on my understanding it is acceptable to have any number of spaces in a DN without escaping them (as long as they are not the first or the last characters in the field). I verified that only a single space is being sent to the remote server by doing a packet capture and looking at the actual LDAP query being sent. If it would help to provide configuration, additional logs, or a packet capture please advise and I can provide this. I believe my overlay proxy works fine otherwise. Dan

1 0

Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by quanah＠zimbra.com 08 Apr '16

08 Apr '16

--On Friday, April 08, 2016 6:02 PM +0000 Frank.Swasey(a)uvm.edu wrote: > This message is in MIME format. The first part should be readable text, > while the remaining parts are likely unreadable without MIME-aware > tools. > > --0-599314220-1460134885=:98440 > Content-Type: text/plain; format=flowed; charset=US-ASCII > > git format-patch version attached. Perfect, thank you! --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs April 2016