- openldap-bugs - openldap.org

Re: (ITS#6103) canceled operations do not respond
by h.b.furuseth＠usit.uio.no 27 May '09

27 May '09

hyc(a)symas.com writes: >Hallvard B Furuseth wrote: >> The send_ldap_response() fix is still incomplete: [Reversing the quoteed message] >> Also, this: >> rc = rs->sr_err; >> if ( rc == SLAPD_ABANDON&& op->o_cancel ) >> rc = LDAP_CANCELLED; >> will send a negative result code (SLAPD_ABANDON) if !o_cancel. > > No, it won't. That is all bypassed at the top of the function. If so, the quoted op->o_cancel test could be skipped. But an overlay could set rs->sr_err = SLAPD_ABANDON during slap_response_play(). Though that ought to mean o_abandon is set, so send_ldap_ber() will drop the message. So you're right after all that it won't be sent. >> Note, not just when the function itself sets rc = LDAP_CANCELLED, >> since syncprov can set rs->sr_err = LDAP_CANCELLED too. >> Which also suggests the assert( rs->sr_err == LDAP_REFERRAL ) when >> sr_ref != NULL is rather dubious. Maybe sr_ref should just >> be ignored when sending something else than LDAP_REFERRAL. > > Leave the assert() in place until you have proof one way or the other. Haven't tested with an example of an overlay setting SLAPD_ABANDON; could check syncprov or retcode I suppose. Faked it with nanosleep(&((struct timespec){0,2E8}), 0); /*gcc or C99 code*/ if ( op->o_abandon ) rs->sr_err = SLAPD_ABANDON; after the op->o_callback->sc_response in slap_response_play(). Then, with this slapd.conf: include servers/slapd/schema/core.schema referral ldap://elsewhere/ database frontend overlay valsort send Delete "cn=urgle" <wait 0.1 second> Abandon <previous request> lt-slapd: result.c:479: send_ldap_response: Assertion `rs->sr_err == 0x0a' failed. One more detail, looking at result.c rev 1.330 send_ldap_response(): I presume the LDAP_CONNECTIONLESS branch should also ber_printf rc rather than rs->sr_err to the response. Not sure if Cancel makes sense in cldap (and after V2 Bind which has no extended operation at that), but OpenLDAP does let through Cancel after a V2 Bind. >> When rc == LDAP_CANCELLED, the function should not send sr_matched, >> sr_text, sr_ref, and sr_ctrls. Looking at how Abandon works, it seems >> slap_cleanup_play() should still see them if they are not sent? > > Dunno what you mean. I thought that was obvious, but since it isn't maybe I should ask ldapext instead. Cancel does seem underspecified in this regard. Anyway, I meant: Either an operation gets cancelled/abandoned, or it doesn't and comletes. If these fields are set, they most likely relate to a completed operation. Nowhere SLAPD_ABANDON gets set, are the others set - possibly except with back-meta/back-ldap, I haven't looked too closely. OTOH, code setting SLAPD_ABANDON rarely _clears_ those fields, so I imagine they can convey information which would have been removed (access controls maybe?) or updated before they were sent, if the operation had completed. Clearing a critical control can be a bit doubtful, I'll grant. But for not obeying critical controls it's a choice between which error code to return - unavailableCriticalExtension, cancelled, or something else. Or some controls could mark the operation as "uncancellable" (another flag needed...) But come to think of it, an Extended Response has some of the same problem. By the above reasoning, responseName and responseValue should be dropped in a Cancelled response, as when sending protocolError to an unrecognized reqest. Might be a bit extreme. -- Hallvard

1 0

Re: (ITS#6103) canceled operations do not respond
by hyc＠symas.com 27 May '09

27 May '09

Hallvard B Furuseth wrote: > The send_ldap_response() fix is still incomplete: > > When rc == LDAP_CANCELLED, the function should not send sr_matched, > sr_text, sr_ref, and sr_ctrls. Looking at how Abandon works, it seems > slap_cleanup_play() should still see them if they are not sent? Dunno what you mean. > Note, not just when the function itself sets rc = LDAP_CANCELLED, > since syncprov can set rs->sr_err = LDAP_CANCELLED too. > Which also suggests the assert( rs->sr_err == LDAP_REFERRAL ) when > sr_ref != NULL is rather dubious. Maybe sr_ref should just > be ignored when sending something else than LDAP_REFERRAL. Leave the assert() in place until you have proof one way or the other. > Also, this: > rc = rs->sr_err; > if ( rc == SLAPD_ABANDON&& op->o_cancel ) > rc = LDAP_CANCELLED; > will send a negative result code (SLAPD_ABANDON) if !o_cancel. No, it won't. That is all bypassed at the top of the function. -- -- 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#6103) canceled operations do not respond
by h.b.furuseth＠usit.uio.no 27 May '09

27 May '09

The send_ldap_response() fix is still incomplete: When rc == LDAP_CANCELLED, the function should not send sr_matched, sr_text, sr_ref, and sr_ctrls. Looking at how Abandon works, it seems slap_cleanup_play() should still see them if they are not sent? Note, not just when the function itself sets rc = LDAP_CANCELLED, since syncprov can set rs->sr_err = LDAP_CANCELLED too. Which also suggests the assert( rs->sr_err == LDAP_REFERRAL ) when sr_ref != NULL is rather dubious. Maybe sr_ref should just be ignored when sending something else than LDAP_REFERRAL. Also, this: rc = rs->sr_err; if ( rc == SLAPD_ABANDON && op->o_cancel ) rc = LDAP_CANCELLED; will send a negative result code (SLAPD_ABANDON) if !o_cancel. I guess it should be if ( rc == SLAPD_ABANDON ) { if ( !op->o_cancel ) goto <cleanup or clean2>; rc = LDAP_CANCELLED; } While we're at it, I suggest to generalize this to avoid sending result codes < 0. Send LDAP_OTHER instead. That's ITS#5328 again. -- Hallvard

1 0

Re: (ITS#6108) unique overlay and rootdn
by hyc＠symas.com 27 May '09

27 May '09

mfn(a)fs-etit.de wrote: > Full_Name: Christopher Dyck > Version: 2.4.11 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (130.83.183.3) > > > I found a strange behavior in the unique overlay. > > unique overlay only works, when a rootdn is specified in the slapd.conf, because > the unique_search function uses the rootdn for searching. (took me hours to > determine why my configuration didn't do it's job) > > Isn't it more reasonable to use the dn with which the add or modify is > performed? Definitely not. The user performing the write may not have sufficient access to see all of the instances of the attribute in question. > Or mention this circumstance at least in the manpage?! Probably. -- -- 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#6141 published: SECURITY: Dynamic configuration perfomance issue
by openldap-its＠OpenLDAP.org 27 May '09

27 May '09

Private ITS#6141 is now publicly readable URL: http://www.OpenLDAP.org/its/?findid=6141

1 0

ITS#6143 published: SECURITY: Dynamic configuration perfomance issue
by openldap-its＠OpenLDAP.org 27 May '09

27 May '09

Private ITS#6143 is now publicly readable URL: http://www.OpenLDAP.org/its/?findid=6143

1 0

(ITS#6148) Need smbk5pwd to support MIT KDC
by hyc＠OpenLDAP.org 27 May '09

27 May '09

Full_Name: Howard Chu Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.67.104.102) Submitted by: hyc This is a reminder to me to investigate how the MIT KDC's LDAP backend works, and how to manage password synchronization there.

1 0

(ITS#6147) slapd should explicitly configure SASL auxprop
by hyc＠OpenLDAP.org 26 May '09

26 May '09

Full_Name: Howard Chu Version: 2.4.16/HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.67.104.110) Submitted by: hyc we need a config option for controlling which auxprop plugins the Cyrus SASL library uses, and it should default to just "slapd". See ITS#6056, the sasldb plugin causes problems and generally isn't useful anyway. (And yes, we probably need to investigate why those problems arise.) Also see ITS#6129, we should take more explicit steps to prevent the ldapdb auxprop from loading.

1 0

(ITS#6146) Note output format in ldapsearch man page DESCRIPTION
by rra＠stanford.edu 26 May '09

26 May '09

Full_Name: Russ Allbery Version: 2.4.11 OS: Debian URL: Submission from: (NULL) (171.66.157.16) A Debian user had some difficulty finding the output format of ldapsearch in the current man page. It's there, under -L, but it's not noted in the DESCRIPTION section. Would it be reasonable to add the sentence: The attributes are displayed using an extended version of LDIF. to the end of the DESCRIPTION section?

1 0

Re: (ITS#6145) Resource leaks shown when running cppcheck against openldap
by hyc＠symas.com 26 May '09

26 May '09

palbert1(a)yahoo.com wrote: > Full_Name: Paul Albert > Version: 2.4.16 > OS: SUSE Linux > URL: N/A > Submission from: (NULL) (198.24.6.168) > > > As part of working on a new project, I'm running cppcheck against various pieces > of code that we'll be using. I downloaded cppcheck version 1.32 and ran it > against open LDAP version 2.4.16. cppcheck reported 18 file descriptor/memory > leaks in the open LDAP code base in addition to 2 bad programming practices > (labeled as style). Visual inspection of the code verified these errors. > > The results are shown below and can be verified by running cppcheck against the > open ldap code: None of which matters, since these are all one-shot commands... > > sleepy code/openldap-2.4.16> ../cppcheck-1.32/cppcheck -q . > [./clients/tools/ldapdelete.c:230]: (error) Resource leak: fp > [./clients/tools/ldapmodrdn.c:233]: (error) Memory leak: entrydn > [./clients/tools/ldapmodrdn.c:233]: (error) Memory leak: rdn > [./clients/tools/ldapmodrdn.c:233]: (error) Resource leak: fp > [./contrib/slapd-modules/dsaschema/dsaschema.c:260]: (error) Memory leak: > saveline > [./libraries/libldap_r/thr_debug.c:575]: (error) Memory leak: t > [./libraries/liblutil/getpass.c:128]: (style) Found 'scanf'. You should use > 'fgets' instead > [./libraries/liblutil/getpass.c:153]: (style) Found 'scanf'. You should use > 'fgets' instead > [./servers/slapd/slapi/slapi_utils.c:2511]: (error) Wrong assignement of an > auto-variable to an effective parameter of a function > [./tests/progs/slapd-addel.c:192]: (error) Memory leak: manager > [./tests/progs/slapd-addel.c:192]: (error) Memory leak: filename > [./tests/progs/slapd-modify.c:194]: (error) Memory leak: manager > [./tests/progs/slapd-modify.c:194]: (error) Memory leak: entry > [./tests/progs/slapd-modrdn.c:177]: (error) Memory leak: manager > [./tests/progs/slapd-read.c:227]: (error) Memory leak: manager > [./tests/progs/slapd-read.c:227]: (error) Memory leak: entry > [./tests/progs/slapd-read.c:227]: (error) Memory leak: filter > [./tests/progs/slapd-search.c:250]: (error) Memory leak: manager > [./tests/progs/slapd-search.c:250]: (error) Memory leak: sbase > [./tests/progs/slapd-search.c:250]: (error) Memory leak: filter > > -- -- 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#6056) Samba4 breaks OpenLDAP over ldapi
by abartlet＠samba.org 26 May '09

26 May '09

--=-Qa9s282ZNKloqhE3QHt5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2009-05-26 at 15:40 +0200, Michael Str=C3=B6der wrote: > abartlet(a)samba.org wrote: > > Samba4 always uses SASL credentials these days (trying to avoid simple > > binds). >=20 > libsasldb2.so is not required for a SASL bind with password-based > mechanism. You can store the passwords in attribute userPassword (in > clear-text). So the security consideration is more about password > storage than SASL vs. simple bind on the wire. Which we already use. Regardless, Howard's great detective work shows it still gets in the way.=20 > > Perhaps it's time to investigate EXTERNAL >=20 > That would be good anyway since in Samba4 the result of standard > provision is LDAPI access anyway. So you could directly map the Unix > user smbd is running as (root?) with authz-regexp to directory user > samba-admin. Well, we already discussed that.. ;-) We did. =20 Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com --=-Qa9s282ZNKloqhE3QHt5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQBKHJj0z4A8Wyi0NrsRAqkfAJ4jsghUdEiUTnOHsmG2Bg9njDe6agCeN4hF aNRmEnt5qtFNRw7WtnaXqto= =midd -----END PGP SIGNATURE----- --=-Qa9s282ZNKloqhE3QHt5--

1 0

(ITS#6145) Resource leaks shown when running cppcheck against openldap
by palbert1＠yahoo.com 26 May '09

26 May '09

Full_Name: Paul Albert Version: 2.4.16 OS: SUSE Linux URL: N/A Submission from: (NULL) (198.24.6.168) As part of working on a new project, I'm running cppcheck against various pieces of code that we'll be using. I downloaded cppcheck version 1.32 and ran it against open LDAP version 2.4.16. cppcheck reported 18 file descriptor/memory leaks in the open LDAP code base in addition to 2 bad programming practices (labeled as style). Visual inspection of the code verified these errors. The results are shown below and can be verified by running cppcheck against the open ldap code: sleepy code/openldap-2.4.16> ../cppcheck-1.32/cppcheck -q . [./clients/tools/ldapdelete.c:230]: (error) Resource leak: fp [./clients/tools/ldapmodrdn.c:233]: (error) Memory leak: entrydn [./clients/tools/ldapmodrdn.c:233]: (error) Memory leak: rdn [./clients/tools/ldapmodrdn.c:233]: (error) Resource leak: fp [./contrib/slapd-modules/dsaschema/dsaschema.c:260]: (error) Memory leak: saveline [./libraries/libldap_r/thr_debug.c:575]: (error) Memory leak: t [./libraries/liblutil/getpass.c:128]: (style) Found 'scanf'. You should use 'fgets' instead [./libraries/liblutil/getpass.c:153]: (style) Found 'scanf'. You should use 'fgets' instead [./servers/slapd/slapi/slapi_utils.c:2511]: (error) Wrong assignement of an auto-variable to an effective parameter of a function [./tests/progs/slapd-addel.c:192]: (error) Memory leak: manager [./tests/progs/slapd-addel.c:192]: (error) Memory leak: filename [./tests/progs/slapd-modify.c:194]: (error) Memory leak: manager [./tests/progs/slapd-modify.c:194]: (error) Memory leak: entry [./tests/progs/slapd-modrdn.c:177]: (error) Memory leak: manager [./tests/progs/slapd-read.c:227]: (error) Memory leak: manager [./tests/progs/slapd-read.c:227]: (error) Memory leak: entry [./tests/progs/slapd-read.c:227]: (error) Memory leak: filter [./tests/progs/slapd-search.c:250]: (error) Memory leak: manager [./tests/progs/slapd-search.c:250]: (error) Memory leak: sbase [./tests/progs/slapd-search.c:250]: (error) Memory leak: filter

1 0

Re: (ITS#6056) Samba4 breaks OpenLDAP over ldapi
by michael＠stroeder.com 26 May '09

26 May '09

abartlet(a)samba.org wrote: > Samba4 always uses SASL credentials these days (trying to avoid simple > binds). libsasldb2.so is not required for a SASL bind with password-based mechanism. You can store the passwords in attribute userPassword (in clear-text). So the security consideration is more about password storage than SASL vs. simple bind on the wire. > Perhaps it's time to investigate EXTERNAL That would be good anyway since in Samba4 the result of standard provision is LDAPI access anyway. So you could directly map the Unix user smbd is running as (root?) with authz-regexp to directory user samba-admin. Well, we already discussed that.. ;-) Ciao, Michael.

1 0

Re: (ITS#6056) Samba4 breaks OpenLDAP over ldapi
by hyc＠symas.com 26 May '09

26 May '09

Michael Ströder wrote: > hyc(a)symas.com wrote: >> Further testing with Andrew's kvm image shows the hang only occurs when Cyrus >> SASL's libsasldb2.so plugin is present. > > Probably you already checked whether there's a BDB library mix. Yes, the version is the same, BDB 4.7. However it's possible that BDB 4.7 doesn't like being initialized multiple times, as occurs here. I haven't yet looked more deeply to see what the real cause is. -- -- 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#6056) Samba4 breaks OpenLDAP over ldapi
by abartlet＠samba.org 26 May '09

26 May '09

--=-oqpE6PlbXuzML9/ubGjQ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2009-05-26 at 04:26 -0700, Howard Chu wrote: > abartlet(a)samba.org wrote: > > Full_Name: Andrew Bartlett > > Version: CVS HEAD > > OS: Fedora 10 > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (59.167.251.137) > > > > > > Samba4's provision and 'make test' seems to create some internal situat= ion in > > OpenLDAP slapd where it will not accept any more connections over ldapi= :/// > > > > This is best seen by building Samba4, and running > > > > TEST_LDAP=3Dyes OPENLDAP_ROOT=3D/usr/local make test > > > > The slapd does not crash, but simply stops accepting new connections. = Samba4 > > currently then crashes due to some other bug (the LDAP backend not resp= onding is > > clearly untested code in Samba4). > > > > It isn't a Samba4 client bug, as ldapsearch also fails to respond. > > > > This seems very, very similar to ITS#5261 >=20 > Further testing with Andrew's kvm image shows the hang only occurs when C= yrus=20 > SASL's libsasldb2.so plugin is present. I always remove that plugin from = my=20 > installs, since I only use in-directory SASL secrets. That's probably why= I=20 > wasn't seeing the reported behavior before. Very interesting result! > Also a note - it's still not clear we've been talking about the same thin= g up=20 > to this point. Even when the samba test suite hangs, I see that ldapsearc= h=20 > still works fine against slapd. At any rate, currently all of the samba4 = tests=20 > pass for me. Samba4 always uses SASL credentials these days (trying to avoid simple binds). Perhaps it's time to investigate EXTERNAL if it would avoid some of this pain (but we should also try and fix the real bug here, if at all possible). =20 Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com --=-oqpE6PlbXuzML9/ubGjQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQBKG99Zz4A8Wyi0NrsRAmqZAJ9Oh4eSbVP7nbGAn0b8tp2hVMbWKQCfZ4Lr pIs94kn/tBYQYq0Qr1uSX44= =CZuG -----END PGP SIGNATURE----- --=-oqpE6PlbXuzML9/ubGjQ--

1 0

Re: (ITS#6056) Samba4 breaks OpenLDAP over ldapi
by michael＠stroeder.com 26 May '09

26 May '09

hyc(a)symas.com wrote: > Further testing with Andrew's kvm image shows the hang only occurs when Cyrus > SASL's libsasldb2.so plugin is present. Probably you already checked whether there's a BDB library mix. Ciao, Michael.

1 0

Re: (ITS#6056) Samba4 breaks OpenLDAP over ldapi
by hyc＠symas.com 26 May '09

26 May '09

abartlet(a)samba.org wrote: > Full_Name: Andrew Bartlett > Version: CVS HEAD > OS: Fedora 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (59.167.251.137) > > > Samba4's provision and 'make test' seems to create some internal situation in > OpenLDAP slapd where it will not accept any more connections over ldapi:/// > > This is best seen by building Samba4, and running > > TEST_LDAP=yes OPENLDAP_ROOT=/usr/local make test > > The slapd does not crash, but simply stops accepting new connections. Samba4 > currently then crashes due to some other bug (the LDAP backend not responding is > clearly untested code in Samba4). > > It isn't a Samba4 client bug, as ldapsearch also fails to respond. > > This seems very, very similar to ITS#5261 Further testing with Andrew's kvm image shows the hang only occurs when Cyrus SASL's libsasldb2.so plugin is present. I always remove that plugin from my installs, since I only use in-directory SASL secrets. That's probably why I wasn't seeing the reported behavior before. Also a note - it's still not clear we've been talking about the same thing up to this point. Even when the samba test suite hangs, I see that ldapsearch still works fine against slapd. At any rate, currently all of the samba4 tests pass for me. -- -- 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

LDAP add *.ldif errors
by Pastore Annamaria 25 May '09

25 May '09

Goodmornig, I load a version 2.4 of LDAP (that support overlay-memberof). Ldap it start ok, and the network was ok. I start to configure a memberof scenarios and after few errors started. For don't touch anymore, I cleanup all /var/lib/ldap...and I try to load A single *.ldif.... but when I try to load a .ldif (core, cosine..) I have few errors : 1. With ldap online : ldapadd -x -D "cn=Manager,dc=pippo,dc=it" -W -f core.ldif Enter LDAP Password: adding new entry "cn=core,cn=schema,cn=config" ldap_add: Insufficient access (50) In /var/lib/ldap there is a DB_CONFIG (before DB_CONFIG.exemple) and the owner of directory is ldap, just I read few threads about this sort of bug. The access in slapd.con is : #access to dn="" by * read access to attrs=userPassword by anonymous auth by self write by * auth # by * none access to * by self write by * read # by * none But anymore I try also whit "by * write" and nothing change. Other parameter is : directory /var/lib/ldap 2. With ldap offline : [root@itmit2vl5 schema]# slapadd -l core.ldif -f ../slapd.conf bdb(dc=telecom,dc=it): Program version 4.4 doesn't match environment version 4.6 bdb_db_open: Database cannot be opened, err -30971. Restore from backup! bdb(dc=pippo,dc=it): DB_ENV->lock_id_free interface requires an environment configured for the locking subsystem bdb(dc=pippo,dc=it): txn_checkpoint interface requires an environment configured for the transaction subsystem bdb_db_close: txn_checkpoint failed: Invalid argument (22) backend_startup_one: bi_db_open failed! (-30971) slap_startup failed But the bdb version not appears anywhere!!! I try also the command "od -j12 -N8 -tx4 log.0000000001" and the result was 4.6! What I must to do, for going on ? Thank you very much at all, and sorry for my newbie expierence..... Internet E. Mail Confidentiality Footer ----------------------------------------------------------------------------------------------------- La presente comunicazione, con le informazioni in essa contenute e ogni documento o file allegato, e' rivolta unicamente alla/e persona/e cui e' indirizzata ed alle altre da questa autorizzata/e a riceverla. Se non siete i destinatari/autorizzati siete avvisati che qualsiasi azione, copia, comunicazione, divulgazione o simili basate sul contenuto di tali informazioni e' vietata e potrebbe essere contro la legge (art. 616 C.P., D.Lgs n. 196/2003 Codice in materia di protezione dei dati personali). Se avete ricevuto questa comunicazione per errore, vi preghiamo di darne immediata notizia al mittente e di distruggere il messaggio originale e ogni file allegato senza farne copia alcuna o riprodurne in alcun modo il contenuto. This e-mail and its attachments are intended for the addressee(s) only and are confidential and/or may contain legally privileged information. If you have received this message by mistake or are not one of the addressees above, you may take no action based on it, and you may not copy or show it to anyone; please reply to this e-mail and point out the error which has occurred.

1 0

Re: (ITS#6139) slapd: password-hash rejects multiple values
by michael＠stroeder.com 25 May '09

25 May '09

fumiyas(a)osstech.co.jp wrote: > My /etc/openldap/slapd.conf has the following line: > password-hash {CRYPT} {SSHA} What exactly do you want to achieve by this? Ciao, Michael.

1 0

Compile error on tru64 5.1b
by Didier Godefroy 25 May '09

25 May '09

Hello, Compiling openldap 2.4.26 on tru64 unix v5.1b, using the native compilers and gmake. I'm getting an error as follows: Entering subdirectory liblunicode gmake[2]: Entering directory `/usr/local/openldap/openldap-2.4.16/libraries/liblunicode' cc -O4 -g3 -w -I../../include -I../../include -pthread -I/usr/local/include -pthread -I/usr/local/include -c -o ure.o ure.c cc: Fatal: A memory access violation (bus error or segmentation fault) has occurred. Please submit a problem report. gmake[2]: *** [ure.o] Error 1 I retried, just in case, and got the same error again. I'm not a C programmer and I have no idea how to fix this. What can I try and send to get this fixed? Thanks, -- Didier Godefroy mailto:dg@ulysium.net Support anti-Spam legislation. Join the fight http://www.cauce.org/

2 1

Re: (ITS#6131) "TLSVerifyClient try" not working with GNU TLS
by hyc＠symas.com 25 May '09

25 May '09

subbarao(a)computer.org wrote: > Full_Name: Kartik Subbarao > Version: 2.4.16 > OS: Debian 5.0.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (76.99.175.5) > > > When TLSVerifyClient is set to "try", OpenLDAP improperly rejects SSL > connections without a client certificate. The problem appears to start with this > section of code in tls.c around line 1564: > > #ifdef HAVE_GNUTLS > if ( ld->ld_options.ldo_tls_require_cert != LDAP_OPT_X_TLS_NEVER ) { > err = tls_cert_verify( ssl ); > if ( err&& ld->ld_options.ldo_tls_require_cert != LDAP_OPT_X_TLS_ALLOW > ) > return err; > } > #endif > > tls_cert_verify() calls gnutls_certificate_verify_peers2(), which appears to > return error 49 when no client certificate is presented. tls_cert_verify() > doesn't seem to distinguish between this case, and the case of an invalid client > certificate, returning -1 in both cases. > This bug report makes no sense; the code you quoted is not part of OpenLDAP 2.4.16. The relevant code is in function tlsg_session_accept() in tls_g.c, and there is no such bug in that function. -- -- 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#6140) nadf.schema: AttributeType not found: "lastModifiedTime"
by michael＠stroeder.com 25 May '09

25 May '09

Full_Name: Michael Ströder Version: RE24 OS: Linux URL: Submission from: (NULL) (84.163.124.107) When including nadf.schema slapd does not start and prints error message: /opt/openldap-RE24/etc/openldap/schema/nadf.schema: line 111 objectclass: AttributeType not found: "lastModifiedTime" /etc/openldap/slapd.conf: line 17: <include> handler exited with 1! Analyzing this I found this commented declaration in cosine.schema: ## Deprecated in favor of modifyTimeStamp #attributetype ( 0.9.2342.19200300.100.1.23 NAME 'lastModifiedTime' # DESC 'RFC1274: time of last modify, replaced by modifyTimestamp' # OBSOLETE # SYNTAX 1.3.6.1.4.1.1466.115.121.1.53 # USAGE directoryOperation ) So it seems nadf.schema is not usable at the moment.

1 0

(ITS#6139) slapd: password-hash rejects multiple values
by fumiyas＠osstech.co.jp 25 May '09

25 May '09

Full_Name: SATOH Fumiyasu Version: 2.4.16 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (115.176.213.88) My /etc/openldap/slapd.conf has the following line: password-hash {CRYPT} {SSHA} On OpenLDAP 2.4.16, slapd (slaptest) rejects this config: # /usr/sbin/slaptest /etc/openldap/slapd.conf: line 36: <password-hash> extra cruft after <hash>. slaptest: bad configuration file! On OpenLDAP 2.3.43, slapd (slaptest) accept this config. The slapd.conf(5) (included in OpenLDAP 2.3.43/2.4.16) manpage said: password-hash <hash> [<hash>...] This option configures one or more hashes to be used in generation of user passwords stored in the userPassword attribute during processing of LDAP Password Modify Extended Operations (RFC 3062).

1 0

Re: (ITS#6104) race condition with cancel operation
by h.b.furuseth＠usit.uio.no 23 May '09

23 May '09

hyc(a)symas.com writes: >> Bitflags should be unnecessary as such, just need a set of values. >> Though it wouldn't hurt if they were chosen so one could use bit >> operations to reduce checks for "o_abandon == A or B". "Suppress >> response" value mentioned in ITS#6138 also needed, maybe that must be a >> bitflag when combined with Cancel stuff. > > Yes, it still seems some bitflags will be more appropriate. As long as we decide which flag combinations are (not) valid. Problem with "unrestricted" bitflags compared to a list of values is that they allow and thus require support for flag combinations we have no real need to support. >> Question: >> syncprov_op_abandon() holds&si->si_ops_mutex when setting >> so->s_op->o_abandon. Does it need that? The function needs to >> grab op->o_conn->c_mutex when called as Cancel, but must not do >> that while holding&si->si_ops_mutex since Abandon grabs the >> locks in the opposite order. > > syncprov_op_abandon() can remove ops from the list, so yes, it must > hold si_ops_mutex. Right, but does it need si_ops_mutex while setting o_abandon? Cancel could remove the op, unlock si_ops_mutex, lock c_mutex, update o_abandon. Alternative: Lock c_mutex first (that must be safe since Abandon is doing it anyway), then lock si_ops_mutex. So it's not a critical difference, just that a lock must be held a bit longer. -- Hallvard

1 0

Re: (ITS#6104) race condition with cancel operation
by hyc＠symas.com 22 May '09

22 May '09

h.b.furuseth(a)usit.uio.no wrote: > Well, this turned out a lot of problems. Currently blocked by > ITS#6138 Bad Cancel/Abandon/"internal abandon"/Syncprov interactions. > > back-relay/op.c done (ITS#6133). syncprov/retcode issues may fit better > under ITS#6138. > > Bitflags should be unnecessary as such, just need a set of values. > Though it wouldn't hurt if they were chosen so one could use bit > operations to reduce checks for "o_abandon == A or B". "Suppress > response" value mentioned in ITS#6138 also needed, maybe that must be a > bitflag when combined with Cancel stuff. Yes, it still seems some bitflags will be more appropriate. > Some tidbits uglifying a fix: > * op->o_conn->c_mutex is locked when be->be_abandon() is called, > but not when be->be_cancel() is called. > * send_ldap_ber() needs the lock while it holds&conn->c_write1_mutex, > but code elsewhere indicates the reverse lock order. > > Question: > syncprov_op_abandon() holds&si->si_ops_mutex when setting > so->s_op->o_abandon. Does it need that? The function needs to > grab op->o_conn->c_mutex when called as Cancel, but must not do > that while holding&si->si_ops_mutex since Abandon grabs the > locks in the opposite order. syncprov_op_abandon() can remove ops from the list, so yes, it must hold si_ops_mutex. -- -- 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs