openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

Re: (ITS#7598) Named MDB database incompatible with some flags
by h.b.furuseth＠usit.uio.no 21 May '13

21 May '13

> mdb_dbi_open(named database) and thus "mdb_stat -a" > crash if the main database has the MDB_DUPSORT flag: > It hits assert(mx != NULL) in mdb_cursor_init(). > > Fixing to reject mdb_dbi_open(named database) in this > case, (...) But then mdb_stat crashes anyway when calling: mdb_cursor_get(cursor, &key, NULL, MDB_NEXT) if a key has several data values. mdb_cursor_get(,,,MDB_NEXT) expects a non-NULL data argument for an MDB_DUPSORT database. It works with MDB_NEXT_NODUP. I think we can drop the doc which says MDB_<NEXT,PREV>_NODUP is only for DUPSORT databases. mdb.c will need no changes that I can see. Or, it works to pass a pointer to an otherwise unused data. But that leaves mdb_stat doing more work than it needs. Another mdb_stat nitpick: It exits with failure after mdb_cursor_get returns an expected MDB_NOTFOUND. Fixing. -- Hallvard

1 0

(ITS#7598) Named MDB database incompatible with some flags
by h.b.furuseth＠usit.uio.no 21 May '13

21 May '13

Full_Name: Hallvard B Furuseth Version: mdb.master, a2ce25482a60e516d1d9b417ed666dac6fdebb93 OS: Linux x86_64 URL: Submission from: (NULL) (193.69.163.163) Submitted by: hallvard mdb_dbi_open(named database) and thus "mdb_stat -a" crash if the main database has the MDB_DUPSORT flag: It hits assert(mx != NULL) in mdb_cursor_init(). Fixing to reject mdb_dbi_open(named database) in this case, and also with MDB_INTEGERKEY which would expect the char* database name to be a binary integer.

1 0

(ITS#7597) migration of sunone 5.2 to openldap 2.4
by univadisitisteam＠hcl.com 21 May '13

21 May '13

Full_Name: venkatesh Version: 2.4 OS: RH5.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (155.91.28.231) HI Team, We have a requirement for migrating existing Sun One 5.2 DS to open ldap 2.4 Authentication.Please guide me how to do this migration. Regards, Venkatesh

1 0

(ITS#7596) OpenLDAP returning incorrect value for "graceAuthNsRemaining"
by nzipsi＠gmail.com 21 May '13

21 May '13

Full_Name: Andrew Thorburn Version: 2.4.35 OS: N/A URL: Submission from: (NULL) (203.97.178.157) The problem is very simple: According to the Behera Password Policy Draft (http://tools.ietf.org/html/draft-behera-ldap-password-policy-10), the attribute graceAuthNsRemaining should be set to the number of grace authentications remaining. However, with the following policy extract: pwdMaxAge: 1 pwdMustChange: TRUE pwdAllowUserChange: TRUE pwdSafeModify: TRUE pwdGraceAuthNLimit: 2 Running ldapwhoami results in the following: ldap_bind: Success (0) (Password expired, 2 grace logins remain) dn:uid=ANDREWT,ou=People,dc=example,dc=com That is not correct - there is only a single grace login remaining. I have used up one of the two grace logins provided by binding to OpenLDAP to execute the ldapwhoami command. Executing the same command twice more results in the following: $ ldapwhoami -h remotehost -e ppolicy -D uid=ANDREWT,ou=People,dc=example,dc=com -w andrew10 ldap_bind: Success (0) (Password expired, 1 grace logins remain) dn:uid=ANDREWT,ou=People,dc=example,dc=com $ ldapwhoami -h remotehost -e ppolicy -D uid=ANDREWT,ou=People,dc=example,dc=com -w andrew10 ldap_bind: Invalid credentials (49); Password expired Whereas I would have assumed, both from the message returned and from the language in the draft, that the first invocation would have said "(Password expired, 1 grace logins remain)", followed by then denying access for the next two invocations. Well, actually, what I would *expect* to happen is the first would return "1 remains", the second "0 remain" and the third would deny access, but the draft policy is pretty explicit, IMO, that the former is what should happen (which is daft). Now, according to the spec: "If there are remaining grace authentications as per Section 7.4, the server adds a new value with the current time in pwdGraceUseTime. Then it sends to the client a response with an appropriate successful resultCode (i.e. success (0), compareTrue (6), etc.), and includes the passwordPolicyResponse in the controls field of the response message with the warning: graceAuthNsRemaining choice set to the number of grace authentications left." This suggests, at least to me, that a new value should be added to pwdGraceUseTime *before* calculating the number of remaining grace logins. Admittedly, that wouldn't actually fix the issue, as it would result in the final grace login failing. Oops. This looks a lot like a bug to me, but at the same time, it also seems to be trying to adhere to the letter of the policy while also doing what is expected (e.g. if pwdGraceAuthNLimit is 1, I should be able to login once, while according to the letter of the policy pwdGraceAuthNLimit: 1 == pwdGraceAuthNLimit: 0...) The simplest fix, at least that I can see, would be to add the statement "ngut--;" at some point after the statement if (ngut < 1) { ppb->pErr = PP_passwordExpired; rs->sr_err = LDAP_INVALID_CREDENTIALS; goto done; } e.g. if (ngut < 1) { ppb->pErr = PP_passwordExpired; rs->sr_err = LDAP_INVALID_CREDENTIALS; goto done; } ngut--; Or perhaps after we've created the grace user time attribute modification. This would be done to account for the fact that we are, right now, using up a single one of the pwdGraceUseTime values, and that once we're done, ngut should indeed be one less than it currently is - there will be (ngut - 1) grace logins *remaining* after this method invocation finishes. This may seem like a really small thing, but it's causing problems for me...

1 0

RE: (ITS#7591) back-meta modify operation not sending result to client
by jorge.perez.burgos＠ericsson.com 20 May '13

20 May '13

Hi, At the end, meta_back_op_result() will map inside the error returned by ldap_modify_ext to LDAP_OTHER, since we don't call it with LDAP_BACK_SENDERR, nothing is sent. Since the error is not LDAP_UNAVAILABLE there will be no retries. I think this happens too in add and delete. BR -----Original Message----- From: Pierangelo Masarati [mailto:pierangelo.masarati@polimi.it] Sent: lunes, 20 de mayo de 2013 21:41 To: Jorge Perez Burgos Cc: openldap-its(a)openldap.org Subject: Re: (ITS#7591) back-meta modify operation not sending result to client On 05/15/2013 08:57 AM, jorge.perez.burgos(a)ericsson.com wrote: > kludge fix for the problem > > --- servers/slapd/back-meta/modify.c 2012-07-31 18:39:26.000000000 +0200 > +++ servers/slapd/back-meta/modify.c 2013-05-14 12:45:39.273333000 +0200 > @@ -176,6 +176,7 @@ > } > modv[ i ] = 0; > > + rs->sr_type = -1; > retry:; > ctrls = op->o_ctrls; > rc = meta_back_controls_add( op, rs, mc, candidate, &ctrls ); @@ > -198,6 +200,10 @@ > } > > cleanup:; > + if (rs->sr_type != REP_RESULT) { > + send_ldap_error(op, rs, LDAP_OTHER, "connection problem trying to reach the other node"); > + } > + > (void)mi->mi_ldap_extra->controls_free( op, rs, &ctrls ); > > if ( mdn.bv_val != op->o_req_dn.bv_val ) { Thanks for the feedback; I am under the impression that a result should have been returned by meta_back_op_result(). Before applying the suggested fix, I would like to understand whether that function was called and in case why it did not send a result. p. -- Pierangelo Masarati Associate Professor Dipartimento di Ingegneria Aerospaziale Politecnico di Milano

1 0

(ITS#7595) OpenLDAP lacks a ECDHE key generation callback
by crest＠tzi.de 20 May '13

20 May '13

Full_Name: Jan Bramkamp Version: 2.4.35 OS: FreeBSD 9.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (79.230.127.217) OpenLDAP supports PFS TLS cipher suites using DHE with the DH *tlso_tmp_dh_cb(SSL*,int,int) callback in libraries/libldap/tls_o.c. DHE-RSA/DSS cipher suites are very CPU intensive and noticeably increase latency on low-power hardware. While OpenLDAP supports ECDH-ECDSA cipher suites these lack the PFS offered by DHE-RSA/DSS cipher suites. >From my initial search it looks like the correct API to register such a callback would be SSL_CTX_set_tmp_ecdh_callback(), but im not familiar the OpenLDAP code base so patching it my self could have unintended consequences. This how the CA was generated: CURVE=secp384r1 openssl ecparam -out private/ca-key.pem -name $CURVE -genkey && openssl req -new -x509 -days 365 -key private/ca-key.pem -out certs/ca-cert.pem openssl ecparam -out private/auth1-key.pem -name $CURVE -genkey && openssl req -new -key private/auth1-key.pem -out newcerts/auth1-csr.pem && openssl ca -config /usr/local/openssl/openssl.cnf -out certs/auth1-cert.pem -infiles newcerts/auth1-csr.pem The (EC)DH paramter file was generated with: openssl ecparam -name $CURVE This was tested with slapd linked against OpenSSL 1.0.1e from ports on FreeBSD 9.1/amd64.

1 0

Re: (ITS#7591) back-meta modify operation not sending result to client
by pierangelo.masarati＠polimi.it 20 May '13

20 May '13

On 05/15/2013 08:57 AM, jorge.perez.burgos(a)ericsson.com wrote: > kludge fix for the problem > > --- servers/slapd/back-meta/modify.c 2012-07-31 18:39:26.000000000 +0200 > +++ servers/slapd/back-meta/modify.c 2013-05-14 12:45:39.273333000 +0200 > @@ -176,6 +176,7 @@ > } > modv[ i ] = 0; > > + rs->sr_type = -1; > retry:; > ctrls = op->o_ctrls; > rc = meta_back_controls_add( op, rs, mc, candidate, &ctrls ); > @@ -198,6 +200,10 @@ > } > > cleanup:; > + if (rs->sr_type != REP_RESULT) { > + send_ldap_error(op, rs, LDAP_OTHER, "connection problem trying to reach the other node"); > + } > + > (void)mi->mi_ldap_extra->controls_free( op, rs, &ctrls ); > > if ( mdn.bv_val != op->o_req_dn.bv_val ) { Thanks for the feedback; I am under the impression that a result should have been returned by meta_back_op_result(). Before applying the suggested fix, I would like to understand whether that function was called and in case why it did not send a result. p. -- Pierangelo Masarati Associate Professor Dipartimento di Ingegneria Aerospaziale Politecnico di Milano

1 0

(ITS#7594) incomplete MDB subdb cursor cleanup
by h.b.furuseth＠usit.uio.no 18 May '13

18 May '13

Full_Name: Hallvard B Furuseth Version: mdb.master 0cdd9dffddf66c730a35f48db2bb02d8bb3e5731 OS: Linux x86_64 URL: Submission from: (NULL) (193.69.163.163) Submitted by: hallvard If a cursor is at a clean subDB page, and its current item is deleted by another cursor, then MDB_GET_CURRENT returns the deleted item. Test program below, run with no args, the "m2/del" output line. If the page was dirty, I instead got (key = old, data = size 0). I don't know if it should give MDB_NOTFOUND instead. That's the test program run with one arg. I did not check what happens if the other cursor rearranged the pages, e.g. split the item off to another page. #include "lmdb.h" #include <assert.h> #include <stdio.h> #include <stdlib.h> int main(int argc, char **argv) { char *fname = "test.mdb"; MDB_env *env; MDB_txn *txn; MDB_dbi dbi; MDB_cursor *mc, *m2; MDB_val key, data; int rc; # define STR2VAL(s) (&(MDB_val){sizeof(s), s}) /* includes final \0 */ # define SHOW(name) printf("%s:\t%s[%zd] -> %s[%zd]\n", name, \ (char*)key.mv_data, key.mv_size, (char*)data.mv_data, data.mv_size) # define E(e) { rc = (e); if (rc) { fprintf(stderr, "%s:%d: %s: %s\n",\ __FILE__, __LINE__, #e, mdb_strerror(rc)); abort(); } } remove(fname); E(mdb_env_create(&env)); E(mdb_env_open(env, fname, MDB_NOSUBDIR, 0666)); E(mdb_txn_begin(env, NULL, 0, &txn)); E(mdb_dbi_open(txn, NULL, MDB_DUPSORT, &dbi)); E(mdb_cursor_open(txn, dbi, &mc)); E(mdb_cursor_put(mc, STR2VAL("a"), STR2VAL("x"), 0)); E(mdb_cursor_put(mc, STR2VAL("a"), STR2VAL("y"), 0)); if (argc < 2) { E(mdb_txn_commit(txn)); E(mdb_txn_begin(env, NULL, 0, &txn)); E(mdb_cursor_open(txn, dbi, &mc)); puts("With clean page:"); } E(mdb_cursor_open(txn, dbi, &m2)); E(mdb_cursor_get(mc, &key, &data, MDB_FIRST)); E(mdb_cursor_get(m2, &key, &data, MDB_FIRST)); SHOW("Name:\tKey -> Data (mv_data[mv_len]):\n" "m2"); E(mdb_cursor_del(mc, 0)); E(mdb_cursor_get(m2, &key, &data, MDB_GET_CURRENT)); SHOW("m2/del"); /* Should output the same as... */ E(mdb_cursor_get(mc, &key, &data, MDB_GET_CURRENT)); SHOW("mc/del"); /* ...this: "a[2] -> [0]". */ mdb_txn_abort(txn); mdb_env_close(env); return 0; }

1 0

Re: (ITS#7589) MDB nodesize issues
by h.b.furuseth＠usit.uio.no 17 May '13

17 May '13

Another issue: This breaks because liblmdb does not change the node size when overwriting an overflow page: mdb_put(txn, dbi, &key, &(MDB_val){9000, val}, 0); mdb_put(txn, dbi, &key, &(MDB_val){1, val}, 0); mdb_get(txn, dbi, &key, &data); assert(data.mv_size != 9000); Fixed by 0cdd9dffddf66c730a35f48db2bb02d8bb3e5731. mdb_cursor_put() said: /* yes, overwrite it. Note in this case we don't * bother to try shrinking the node if the new data * is smaller than the overflow threshold. */ It's number of pages which does not need to shrink. -- Hallvard

1 0

Re: (ITS#7577) hdb and mdb derefere aliases differently
by hyc＠symas.com 17 May '13

17 May '13

Juergen.Sprenger(a)swisscom.com wrote: > tried the fix fb537d747c6fd43e08986e99b1fe7781660feaf3 There was a followup commit also needed. 201ddbe3e4d8eb39830b96eefa559900952bc022 Just get the latest. -- -- 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs