openldap-bugs November 2010

openldap-bugs@openldap.org

32 participants
103 discussions

Re: (ITS#6603) EAGAIN, EWOULDBLOCK occasionally used without checking #ifdef
by masarati＠aero.polimi.it 23 Nov '10

23 Nov '10

>> At least in libldap and liblber EAGAIN and EWOULDBLOCK are >> occasionally used without checking whether they are defined or not. >> Either the checks should be removed, counting on the fact that these >> error codes are always defined, or they should be used consistently. > > I'd say the libldap #ifdefs can safely be removed by now: "cvs annotate" > says os-ip.c has had unconditional EWOULDBLOCK since rev 1.34 (Aug > 1999), and request.c unconditional EAGAIN since rev 1.85 (Aug 2002). > No bug reports since then... > > We need to keep the '#if EWOULDBLOCK != EAGAIN's in switches, though. > > liblber always #ifdefs them, except in a test program. I suppose these > #ifdefs could stay in case someone uses the liblber source stand-alone. Here's a patch, please inspect. <ftp://ftp.openldap.org/incoming/pierangelo.masarati.2010-11-23.1.patch> p.

1 0

(ITS#6724) Feature request: support for PKCS11 pin input callback in public TLS api
by silvan＠kernelconcepts.de 23 Nov '10

23 Nov '10

Full_Name: Silvan Marco Fin Version: OS: Ubuntu Linux 10.04 URL: Submission from: (NULL) (217.146.132.69) Support for PKCS #11 devices in TLS via MozNSS in OpenLDAP currently lacks the possibility to "ask" for a PIN via callback. The methods supplied in tls_m.c are reading a PIN from a file or alternativly reading a PIN from STDIN. To add the needed flexibility to the MozNSS part, an additional callback argument to the init function or alternatively an additional set function for the callback would be needed. http://www.mozilla.org/projects/security/pki/nss/ref/ssl/pkfnc.html#1023128 provides the signature for the callback function. Since GnuTLS and OpenSSL provide PKCS #11 support by themselves in some way, I propose to add an additional set function to OpenLDAPs public TLS API to register a callback with the corresponding security library.

1 0

Re: (ITS#5421) slapd vs LDAP_R_COMPILE
by h.b.furuseth＠usit.uio.no 23 Nov '10

23 Nov '10

Taken to this thread: http://www.openldap.org/lists/openldap-devel/201011/msg00013.html librewrite & co vs. logging & ldap-int.h Since this ITS now depends on the ldap_debug hack in ldap_log.h, I'm removing some unnecessary '#include <ldap_log.h>'s for clarity. -- Hallvard

1 0

(ITS#6603) EAGAIN, EWOULDBLOCK occasionally used without checking #ifdef
by h.b.furuseth＠usit.uio.no 23 Nov '10

23 Nov '10

> At least in libldap and liblber EAGAIN and EWOULDBLOCK are > occasionally used without checking whether they are defined or not. > Either the checks should be removed, counting on the fact that these > error codes are always defined, or they should be used consistently. I'd say the libldap #ifdefs can safely be removed by now: "cvs annotate" says os-ip.c has had unconditional EWOULDBLOCK since rev 1.34 (Aug 1999), and request.c unconditional EAGAIN since rev 1.85 (Aug 2002). No bug reports since then... We need to keep the '#if EWOULDBLOCK != EAGAIN's in switches, though. liblber always #ifdefs them, except in a test program. I suppose these #ifdefs could stay in case someone uses the liblber source stand-alone. -- Hallvard

1 0

(ITS#6723) test programs break on EOF
by h.b.furuseth＠usit.uio.no 23 Nov '10

23 Nov '10

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.157.206.208) Submitted by: hallvard tests/progs/slapd-tester.c and libraries/libldap/dntest.c use uninitialized buffer data on EOF from stdin. Fixing.

1 0

Re: (ITS#6721) uninitialized timeout in back-ldap
by h.b.furuseth＠usit.uio.no 23 Nov '10

23 Nov '10

Pierangelo Masarati writes: > The way I read the code (at the time of the ITS#6282) if tv_sec < 0 no > timeout was used. In any case, your fix is fine for me. Looking closer, the valgrind complaint was just for Debug() statements. So we can downgrade this ITS description to Fix back-ldap debug output of timeout -- Hallvard

1 0

Re: (ITS#6721) uninitialized timeout in back-ldap
by masarati＠aero.polimi.it 23 Nov '10

23 Nov '10

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: 4.2.19 - 4.2.23 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > ITS#6282 introduced > struct timeval tv; > tv.tv_sec = -1; > in back-ldap: extended.c and config.c. This leaves tv_usec uninitialized > and the timeout possibly positive. Fixing to: > struct timeval tv = { -1, 0 }; > The way I read the code (at the time of the ITS#6282) if tv_sec < 0 no timeout was used. In any case, your fix is fine for me. p.

1 0

Re: (ITS#6722) Sortvals broken for some matching rules
by h.b.furuseth＠usit.uio.no 23 Nov '10

23 Nov '10

I wrote: > - The sortvals doc should say it need not sort by ORDERING. Fixing. Never mind that one, I must have looked cross-eyed on the manpage. -- Hallvard

1 0

(ITS#6722) Sortvals broken for some matching rules
by h.b.furuseth＠usit.uio.no 23 Nov '10

23 Nov '10

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.157.206.208) Submitted by: hallvard slapd.conf:sortvals sorts attribute values by the EQUALITY rule's match result, which can be faster than ORDERING. Or octetStringMatch when no EQUALITY rule, I suppose. Haven't looked closely. However, (1) When an attribute has sortvals set, filtering by the ORDERING rule only tests first/last value. This breaks when the EQUALITY rule gives a different sort order. E.g. string equality sorts by length before contents of the normalized value, for speed. (2) Sortvals should only be settable for attributes whose EQUALITY rule: - imposes an absolute ordering, - always succeeds. At least, this seems cleanest to me. Currently there are no such restrictions: - At least booleanMatch() returns 0 or 1, never -1. Thus (TRUE, FALSE) sort randomly. And we cannot control third-party dynamically loaded EQUALITY rules, nor is it documented they should impose an ordering. - attr_valfind() proceeds with the binary search when value_match() fails so the 'match' to partition by is unknown. This makes little sense, attr_valfind() should fail when this happens. Thus setting sortvals could break previously working functionality, which is why I think it may be better to forbid sortvals for attributes where this can happen. Alternatively, we could allow it if the user sets an "I really mean it" mark for the attribute. (3) Also it makes me nervous to see search.c in back-ldap + back-meta react to SLAP_AT_SORTED_VAL. Are there other backends/overlays which need to do the same? Can some/most of that code be moved into slapd? Fixes for (1)-(2): - Sortvals needs some new flags: One to allow SLAP_AT_SORTED_VAL. SLAP_ATTR_SORT_IS_ORDERING to tell filterentry that ORDERING can use sortvals. And something to help set SLAP_ATTR_SORT_IS_ORDERING. The first would be set for the relevant equality matching rules. Not sure of the last: It could almost be set if (equality rule == ordering rule), but matching rules are passed as parameters so their implementation can act differently for EQUALITY and ORDERING:-( - filterentry.c:test_ava_filter() should ignore SLAP_ATTR_SORTED_VALS if (use == SLAP_MR_ORDERING) && (SLAP_ATTR_SORT_IS_ORDERING is not set). - booleanMatch() needs a fix. Don't know which others, except a marginal case: Rules that can set *matchp = (int) (value->bv_len - asserted->bv_len) need to be more careful when sizeof(ber_len_t) > sizeof(int). I assume we can safely truncate to ber_slen_t, i.e. that OpenLDAP would fail anyway for values with bv_len > max ber_slen_t. I'll fix this where I see it, but I leave the rest to someone else. - attr_valfind() should abort the binary search on failure. Possibly some of its callers must be updated to handle more result codes. In theory it shouldn't happen anyway with my other suggestions, but this looks hairy enough that it seems best to be safe. - The sortvals doc should say it need not sort by ORDERING. Fixing. ################################ Test case: #### sortvals.conf include servers/slapd/schema/core.schema attributetype ( 1.3.6.1.4.1.4203.666.777.1 NAME 'boolTest' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 ) # dnQualifier has string syntax and an ORDERING rule. sortvals boolTest dnQualifier database hdb directory sortvals.dir suffix st=top # shut up monitor warning database monitor #### sortvals.ldif dn: st=top boolTest: TRUE boolTest: FALSE dnQualifier: bbbb dnQualifier: dd dnQualifier: aaaa objectClass: locality objectClass: extensibleObject st: top dn: st=sub,st=top boolTest: FALSE boolTest: TRUE dnQualifier: aa dnQualifier: dddd objectClass: locality objectClass: extensibleObject st: sub #### sortvals.sh #!/bin/sh -e mkdir sortvals.dir touch sortvals.dir/DB_CONFIG servers/slapd/slapadd -f sortvals.conf -l sortvals.ldif (servers/slapd/slapcat -f sortvals.conf && echo === && servers/slapd/slapcat -f sortvals.conf -a '(dnQualifier<=c)' ) | egrep '^($|[bd=])' #### slapcat output # boolTest sorted differently in the two entries, # 2nd slapcat skips entry #1 since dd <= c even though it has aaaa <= c. dn: st=top boolTest: TRUE boolTest: FALSE dnQualifier: dd dnQualifier: aaaa dnQualifier: bbbb dn: st=sub,st=top boolTest: FALSE boolTest: TRUE dnQualifier: aa dnQualifier: dddd === dn: st=sub,st=top boolTest: FALSE boolTest: TRUE dnQualifier: aa dnQualifier: dddd

1 0

(ITS#6721) uninitialized timeout in back-ldap
by h.b.furuseth＠usit.uio.no 23 Nov '10

23 Nov '10

Full_Name: Hallvard B Furuseth Version: 4.2.19 - 4.2.23 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.240.6.233) Submitted by: hallvard ITS#6282 introduced struct timeval tv; tv.tv_sec = -1; in back-ldap: extended.c and config.c. This leaves tv_usec uninitialized and the timeout possibly positive. Fixing to: struct timeval tv = { -1, 0 };

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs November 2010