- openldap-bugs - openldap.org

Re: (ITS#4978) slapo-ppolicy.5 and missing Zero value example
by hyc＠symas.com 22 May '07

22 May '07

ahasenack(a)terra.com.br wrote: > On Mon, May 21, 2007 at 09:25:23PM +0000, ghenry(a)OpenLDAP.org wrote: >> draft-behera-ldap-password-policy-xx.txt and ppolicy.schema list: >> >> "A 000001010000Z value means that the account has been locked permanently, and >> that only a password administrator can unlock the account." >> >> But pwdAccountLockedTime doesn't use integerMatch, so an example of the above >> syntax is needed with anything that has a generalizedTimeMatch. I think >> pwdAccountLockedTime is the only one? > > The slapo-ppolicy(5) manpage is actually misleading. It implies that > the value is a plain zero, which doesn't work: > "If pwdAccountLockedTime is set to zero (0), the user's account (...)" That text in the manpage came from an earlier revision of the ppolicy draft; it just wasn't updated when the meaning was clarified in a later draft version. Looks like Gavin has fixed it in HEAD now. -- -- Howard Chu Chief Architect, 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#4978) slapo-ppolicy.5 and missing Zero value example
by ahasenack＠terra.com.br 22 May '07

22 May '07

On Mon, May 21, 2007 at 09:25:23PM +0000, ghenry(a)OpenLDAP.org wrote: > draft-behera-ldap-password-policy-xx.txt and ppolicy.schema list: > > "A 000001010000Z value means that the account has been locked permanently, and > that only a password administrator can unlock the account." > > But pwdAccountLockedTime doesn't use integerMatch, so an example of the above > syntax is needed with anything that has a generalizedTimeMatch. I think > pwdAccountLockedTime is the only one? The slapo-ppolicy(5) manpage is actually misleading. It implies that the value is a plain zero, which doesn't work: "If pwdAccountLockedTime is set to zero (0), the user's account (...)"

1 0

(ITS#4979) Bad response when requesting bad attributes
by elecharny＠apache.org 22 May '07

22 May '07

Full_Name: Emmanuel Lecharny Version: 2.3.32 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.236.207.89) When searching for entries using attributes to filter the result, you get all the entries attributes if you give a wrong attribute : ldapsearch -h localhost -p 10389 -D "uid=Admin,ou=system" -w secret -b "dc=example,dc=com" -s sub "(objectClass=*)" 9.9.9 will correctly returns only the DNs of all found entries, as if the 9.9.9 attribute was 1.1 but ldapsearch -h localhost -p 10389 -D "uid=Admin,ou=system" -w secret -b "dc=example,dc=com" -s sub "(objectClass=*)" person will return all entries attributes, as if the 'person' was substituted by "*" Of course, 'person' is not an attribute, but an objectClass, but the user intent was to get only one single attribute value, so I don't think that returning everything is correct. This is obviously not a serious issue.

1 0

Re: (ITS#4951) [contrib] RADIUS password module fixes
by ando＠sys-net.it 22 May '07

22 May '07

richton(a)nbcs.rutgers.edu wrote: >>> * config_filename could be passed to rad_config without initialization (when >>> accepting the default). >> rejected: global variables are always zeroed. > > Hmmmm. I agree that a static pointer variable should be NULL, but it's > definitely not what I'm seeing in dbx. I'll try and take it up with the > Sun Studio people... If that's an issue, I have no problem in explicitly setting that pointer to NULL. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#4951) [contrib] RADIUS password module fixes
by richton＠nbcs.rutgers.edu 22 May '07

22 May '07

>> * config_filename could be passed to rad_config without initialization (when >> accepting the default). > > rejected: global variables are always zeroed. Hmmmm. I agree that a static pointer variable should be NULL, but it's definitely not what I'm seeing in dbx. I'll try and take it up with the Sun Studio people... The rest looks OK, thanks.

1 0

Re: (ITS#4966) OpenLDAP 2.3.35 crashes on valsort overlay
by digant＠stanford.edu 22 May '07

22 May '07

Nothing that useful i could find: $4 = { sml_mod = { sm_op = 1, sm_flags = 0, sm_desc = 0x2aedc50244d0, sm_type = { bv_len = 20, bv_val = 0x2aabae9df741 "suorgcontactstanford" }, sm_values = 0x0, sm_nvalues = 0x0 }, sml_next = 0x2aaaaaaf4ee0 }

1 0

(ITS#4978) slapo-ppolicy.5 and missing Zero value example
by ghenry＠OpenLDAP.org 21 May '07

21 May '07

Full_Name: Gavin Henry Version: 2.3.35 and HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry Dear all, draft-behera-ldap-password-policy-xx.txt and ppolicy.schema list: "A 000001010000Z value means that the account has been locked permanently, and that only a password administrator can unlock the account." But pwdAccountLockedTime doesn't use integerMatch, so an example of the above syntax is needed with anything that has a generalizedTimeMatch. I think pwdAccountLockedTime is the only one? Please correct me if I'm wrong, otherwise I'll update the man page. Thanks, Gavin.

1 0

(ITS#4977) check parse_sync_cookie return in syncprov overlay
by donn＠u.washington.edu 21 May '07

21 May '07

Full_Name: Donn Cave Version: 2.4.4 OS: Red Hat RHEL 3 URL: Submission from: (NULL) (128.95.135.150) Control from 2.3.24 syncrepl client fails "sid=" parse in slap_parse_sync_cookie(), but return -1 is ignored, in syncprov_parseCtrl() ca. line 2770. slapd crashes in syncprov_op_search ca. line 2106, because srs->sr_state.sids is null. Reproduce by sending control with invalid "sid=" value. That might be any 2.3 client, or there may be something else whacked here. Client configured refreshAndPersist. I added a check for negative return value to the check for negative rid. Result is "err=2 nentries=0 text=Sync control : cookie parsing error", ... "do_search: get_ctrls failed", which I assume is good. At least, it doesn't crash.

1 0

Re: (ITS#4975) --without-tls is broken
by hyc＠symas.com 21 May '07

21 May '07

hyc(a)symas.com wrote: > ando(a)sys-net.it wrote: >>> I haven't kept track of the TLS changes though, so I don't know if just >>> moving #ifdefs around is the right fix. >> As far as I understood it, the rationale of those changes was to be able >> to handle, and significantly parse certificates, independently of any TLS >> capability (including when no TLS is available). If you find a >> combination of #ifdef's that gives this, then it should be the right one. > > Your understanding is correct. I can sort this out if you haven't already. > -- -- Howard Chu Chief Architect, 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#4965) slapd stops if access to cn=monitor is restricted
by ando＠sys-net.it 21 May '07

21 May '07

ali.pouya(a)free.fr wrote: > Hi Pierangelo; > I tested with HEAD (checked out on Sunday Mai 20) but the problem is > the same : To configure the Monitor database I have to grant read acces > to *. Can you post your slapd.conf? Thanks, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#4965) slapd stops if access to cn=monitor is restricted
by ali.pouya＠free.fr 21 May '07

21 May '07

Hi Pierangelo; I tested with HEAD (checked out on Sunday Mai 20) but the problem is the same : To configure the Monitor database I have to grant read acces to *. I confirm that I do not have a default rootdn for Monitor. Best Regards Ali

1 0

Re: (ITS#4976) memory corruption in test008-concurrency
by hyc＠symas.com 21 May '07

21 May '07

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD, RE23 > OS: Linux > URL: > Submission from: (NULL) (129.240.202.105) > Submitted by: hallvard > > > Slapd sometimes crashes with memory corruption in test008-concurrency. Try using ElectricFence, with my pthread patches. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#4976) memory corruption in test008-concurrency
by h.b.furuseth＠usit.uio.no 20 May '07

20 May '07

Full_Name: Hallvard B Furuseth Version: HEAD, RE23 OS: Linux URL: Submission from: (NULL) (129.240.202.105) Submitted by: hallvard Slapd sometimes crashes with memory corruption in test008-concurrency. ./configure LIBS="-lmcheck" (a glibc memory checking library) provokes the bug regularly: it dumps core after reporting "memory clobbered before allocated block" somewhere in the test output. It still happens with no avoidable non-OpenLDAP packages (testing with back-null or back-ldif): bash$ ./configure --disable-backends --enable-null --disable-overlays \ --without-cyrus-sasl --without-tls --quiet LIBS="-lmcheck" "configure --without-threads" seems to prevent the crash, so I presume it's thread-related. So far, Valgrind has prevented it too:-( If someone has Purify, maybe that can find it. Patch needed to test with back-null: --- tests/data/slapd.conf~ 2007-01-06 20:35:00 +0100 +++ tests/data/slapd.conf 2007-05-19 19:45:23 +0200 @@ -40,3 +40,6 @@ suffix "dc=example,dc=com" -directory @TESTDIR@/db.1.a +#bdb#directory @TESTDIR@/db.1.a +#hdb#directory @TESTDIR@/db.1.a +#ldif#directory @TESTDIR@/db.1.a +#null#bind on rootdn "cn=Manager,dc=example,dc=com" --- tests/scripts/acfilter.sh~ 2007-01-06 20:35:00 +0100 +++ tests/scripts/acfilter.sh 2007-05-19 20:01:19 +0200 @@ -15,4 +15,5 @@ # -# Strip comments +# Strip comments, or remove everything with back-null # -grep -v '^#' + +test "$BACKEND" = "null" || grep -v '^#' Test loop: cd tests try() { ulimit -c unlimited echo ./run -b $1 test008 nice ./run -b $1 test008 && test "`echo core*`" = "core*" } (declare -i n=0; while try null && try ldif; do n=$n+1; echo "#$n done"; done) I don't see anything from the backtraces, they report when the problem is noticed instead of when it is created. E.g.: #0 0x0039e7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x003df7a5 in raise () from /lib/tls/libc.so.6 #2 0x003e1209 in abort () from /lib/tls/libc.so.6 #3 0x00413a1a in __libc_message () from /lib/tls/libc.so.6 #4 0x00413a54 in __libc_fatal () from /lib/tls/libc.so.6 #5 0x0041fddf in mabort () from /lib/tls/libc.so.6 #6 0x0041f655 in freehook () from /lib/tls/libc.so.6 #7 0x0041a5e5 in free () from /lib/tls/libc.so.6 #8 0x080fea27 in ber_bvarray_free (a=0x0) at memory.c:744 #9 0x0806a34e in attr_clean (a=0x4dfff4) at attr.c:134 #10 0x0806a454 in attrs_free (a=0x8e56204) at attr.c:194 #11 0x0806b0c9 in entry_clean (e=0x8e4bdd4) at entry.c:473 #12 0x0806b142 in entry_free (e=0x8e4bdd4) at entry.c:483 #13 0x0806e898 in be_entry_release_rw (op=0x8e84c78, e=0x8e4bdd4, rw=6) at backend.c:797 #14 0x08069221 in do_add (op=0x8e84c78, rs=0xb59fe154) at add.c:197 #15 0x080626e7 in connection_operation (ctx=0xb59fe228, arg_v=0x8e84c78) at connection.c:1145 #16 0x08062d44 in connection_read_thread (ctx=0xb59fe228, argv=0xa) at connection.c:1271 #17 0x080dc75a in ldap_int_thread_pool_wrapper (xpool=0x8e04fe8) at tpool.c:725 #18 0x006193cc in start_thread () from /lib/tls/libpthread.so.0 #19 0x00480c3e in clone () from /lib/tls/libc.so.6

1 0

Re: (ITS#4975) --without-tls is broken
by h.b.furuseth＠usit.uio.no 20 May '07

20 May '07

Fixed in HEAD. -- Regards, Hallvard

1 0

Re: (ITS#4975) --without-tls is broken
by hyc＠symas.com 20 May '07

20 May '07

ando(a)sys-net.it wrote: >> I haven't kept track of the TLS changes though, so I don't know if just >> moving #ifdefs around is the right fix. > > As far as I understood it, the rationale of those changes was to be able > to handle, and significantly parse certificates, independently of any TLS > capability (including when no TLS is available). If you find a > combination of #ifdef's that gives this, then it should be the right one. Your understanding is correct. I can sort this out if you haven't already. -- -- Howard Chu Chief Architect, 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#4975) --without-tls is broken
by ando＠sys-net.it 20 May '07

20 May '07

> I haven't kept track of the TLS changes though, so I don't know if just > moving #ifdefs around is the right fix. As far as I understood it, the rationale of those changes was to be able to handle, and significantly parse certificates, independently of any TLS capability (including when no TLS is available). If you find a combination of #ifdef's that gives this, then it should be the right one. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#4975) --without-tls is broken
by h.b.furuseth＠usit.uio.no 20 May '07

20 May '07

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux URL: Submission from: (NULL) (129.240.202.105) Submitted by: hallvard slapd/schema_init.c:certificateExactNormalize() (outside HAVE_TLS) needs slapd/dn.c:dnX509normalize() (inside HAVE_TLS). The latter uses libldap/tls.c:ldap_X509dn2bv() (outside HAVE_TLS), which needs oid_name oids[] (inside HAVE_TLS). If those are all moved outside HAVE_TLS, test021-certificate still fails: Running ./scripts/test021-certificate... running defines.sh Running slapadd to build slapd database... Starting slapd on TCP/IP port 9011... Testing certificate handling... Add certificates... ldapmodify failed (18)! ...because certificateExactNormalize() isn't used (the certificateExactMatch syntax #ifdef HAVE_TLS'es it out). It passes if that #ifdef is removed too. I haven't kept track of the TLS changes though, so I don't know if just moving #ifdefs around is the right fix.

1 0

(ITS#4974) tls calls ldap_pvt_thread_self with wrong prototype
by h.b.furuseth＠usit.uio.no 20 May '07

20 May '07

Full_Name: Hallvard B Furuseth Version: HEAD, RE23 OS: URL: Submission from: (NULL) (129.240.202.105) Submitted by: hallvard libldap/tls.c calls CRYPTO_set_id_callback(ldap_pvt_thread_self), which causes ldap_pvt_thread_self to be called with the wrong prototype. That can cause OpenSSL to use a garbage value, e.g. if the unsigned long it expects takes two words but ldap_pvt_thread_t is an int. I'm fixing it in HEAD now and also inserting a check for whether ldap_pvt_thread_t fits in an unsigned long. Maybe the latter should go in configure, but since OpenSSL presumably breaks anyway if that fails I don't see much point at this time.

1 0

Re: (ITS#4958) slapd segfaults when overlay rwm, suffixmassage is used in conjunction with empty suffix
by ando＠sys-net.it 19 May '07

19 May '07

nvoutsin(a)noc.uoa.gr wrote: > As ando already said: > .....it tries to lookup a database to relay for when unbinding, > but unbind has no DN, so a strcmp on NULL is performed. This does not > happen when using the "relay" directive because relay database selection > does not occur for each operation.... Technically, the bug is now fixed in HEAD/re23 (please test). Concerning the issue initially raised on the -software list, which seems to be open yet, see discussion on the list. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#4964) consumer with slapo-chain segfaults when using ldappasswd
by ando＠sys-net.it 19 May '07

19 May '07

This is now completely fixed in HEAD; I need to check any issue related to backporting to re23, for quick release. Please test. Thanks for reporting, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#4973) Inconsistent initialization of internal modifications
by ando＠sys-net.it 19 May '07

19 May '07

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando While fixing slapo-chain(5) handling of passmods, I stumbled into an inconsistent initialization of internal modifications. What happens is that in most cases the Operation structure used for internal operations is either directly the structure passed to the function that performs the internal operation, or a copy of it, something like Operation op2 = *op; The oq_modify.rs_modlist member now contains an orm_no_opattrs field which, if non-zero, inhibits the modification of operational attributes, and thus indirectly breaks replication. I've fixed the occurrence in passwd_extop(), but the code is full of internal modifications that might need care. p.

1 0

Re: (ITS#4078) test001 fails on sparcv9
by h.b.furuseth＠usit.uio.no 19 May '07

19 May '07

I've updated and applied a patch I had lying around for this one: Give OperationBuffer struct members instead of using LBER_ALIGNED_BUFFER. -- Regards, Hallvard

1 0

Re: (ITS#4966) OpenLDAP 2.3.35 crashes on valsort overlay
by ando＠sys-net.it 18 May '07

18 May '07

digant(a)stanford.edu wrote: > When modding an entry, valsort seems to have crashed the server. I've uploaded > the stack trace and informaiton I was able to gather out of the core dump. In your upload: > #0 valsort_modify (op=0x2aabaeac0058, rs=0x417fef10) at valsort.c:455 > 455 for (i=0; !BER_BVISNULL( &ml->sml_values[i] ); i++) { can you detail what operation caused this? Can you print: ml, i, ml->sml_mod.sm_values, ml->sml_mod.sm_values[i] ? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#4959) replica seg faults if syncrepl searchbase =""
by ando＠sys-net.it 18 May '07

18 May '07

ali.pouya(a)free.fr wrote: > The HEAD misses the definition of 'oids' 'oid_name', etc. So I get the following > error at build time : You probably caught HEAD in some inconsistent state during the addition of GNUTLS support; it's working just fine for me. Can you retry? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#4961) If database suffix is ""
by ando＠sys-net.it 18 May '07

18 May '07

ali.pouya(a)free.fr wrote: > Unfortunately the problem has not been completely fixed in the HEAD. > With the fix in the head the error message disappears but the contextCSN ins NOT > ACTUALLY written to the disk. So at the next slapd startup the ContextCSN is > missing. An the servers hav to resynchronize. > > Below you find the log extract. Makes sense: the empty entry "" is not persistent... p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs