openldap-bugs

openldap-bugs@openldap.org

1 participants
20965 discussions

Re: (ITS#5440) back-meta opens too many connections in case of error
by ando＠sys-net.it 01 Apr '08

01 Apr '08

Ali Pouya wrote: > Hi Pierangelo; > > When trying to reproduce the problem with test035 material I found a > problem in my own JAVA code ! > There is no such problem in back-meta :-) > Sorry for misreporting and thanks for your help. OK, no problem. I note that the issue I fixed in HEAD is basically related to not using pseudoroot-bind-defer yes The default is "no", basically to preserve the original behavior. The original behavior consisted in always binding to all targets when bound as the rootdn. When "pseudoroot-bind-defer" is set to "yes", the bind only occurs locally at the proxy, and is propagated to the targets only when they actually need to be used. The reason is that binding as the rootdn might only be needed to operate on a subset of the targets, so there is no need to add extra traffic to those outside this set. When "pseudoroot-bind-defer" is set to "yes", this no longer occurs, and the issue I observed does not show up any longer. Probably, as an outcome of this ITS, we should change the default to "yes". 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#5340) REP_ENTRY_MODIFIABLE bug in dynlist
by h.b.furuseth＠usit.uio.no 01 Apr '08

01 Apr '08

Pierangelo Masarati writes: > Hallvard B Furuseth wrote: >> But I don't see how the be_release() code can work now. It sounds like >> be->be_release() functions must check (how?) that the entry was created >> by 'be', and otherwise pass it on to the next overlay/backend or >> otherwise to entry_free(). Might involve mucking with op->o_bd and >> sr_entry->e_private, I suppose. Except maybe I'm missing some existing >> magic since slapd doesn't regularly crash... > > Yes, but that's trivial: e_private must be NULL for temporary entries, > and copying the entry loses it (no one is supposed to muck with it > expect the entry's creator). OK... > And the appropriate o_bd of a > (non-modifiable) entry can be easily computed from the entry's DN. Hm? Can only the "outermost" backend/overlay create non-modifiable entries? I think any overlay can replace a non-modifiable rs->sr_entry value, as long as it restores it on the way out (unless mustbe<freed/released>). >>> Similarly, the existence of REP_ENTRY_MUSTBEFREED is not totally clear: >>> in principle as soon as REP_ENTRY_MODIFYABLE is set, it should imply >>> REP_ENTRY_MUSTBEFREED; the only difference in the semantics of the two >> >> That's not my impression. (...) Some functions create entries on the stack an send them MODIFIABLE - but obviously without MUSTBEFREED. They use entry_clean() instead. Others set MODIFIABLE but not MUSTBEFREED on non-stack entries, and call entry_free after sending it. Or forget to free it - back-perl/search.c if LDAP_SIZELIMIT_EXCEEDED. (Not patching yet - don't have time to test it at the moment.) > (...) A copy might be created by an overlay after receiving a > read-only entry, but the same overlay might not actually perform the > copy if it receives the entry from another overlay that already copied > it, or from a proxy backend. However, after the entry is copied the > overlay will have no means to determined who actually created the copy. I don't think it matters who created a MUSTBEFREED copy: > This might be an issue depending on the order cleanup handlers are > called (didn't check what order they're called). My point is that > temporary entries need to be freed at some point; who frees them should > not be relevant... Right, someone must call entry_free() and clear rs->sr_entry (so it's not freed again), but entry_free() is not passed a backend parameter. OTOH a MUSTBERELEASED entry must be released by the right backend/overlay, and it would be strange for such an entry to be MODIFIBALE. Though I guess it could be - if the backend has no cache, and be_release just exists to clean up some data in e_private. >> Others apparent problems (also not tested, I've just browsed the code): >> Overlays that obey and reset MUSTBEFREED or MUSTRELEASE, do not >> necessarily clear or set MODIFIABLE when setting a new entry. >> (...) > > It seems to me that we should provide "smart" handlers to deal with > preparing sr_entry for modification, and to take care of cleaning things > up as appropriate. Those helpers should then be consistently used in > the code. Yup. And add some aggressive asserts - at least #ifdef LDAP_DEVEL. Don't know when I'll have time for it though. -- Hallvard

1 0

Re: (ITS#5448) CONTRIB: Java slapd
by ando＠sys-net.it 01 Apr '08

01 Apr '08

hyc(a)OpenLDAP.org wrote: > Given the increasing popularity of Java, I decided it was time that the > OpenLDAP Project had its own Java implementation of an LDAP server. It > gave me a good opportunity to explore all of the benefits of rapid > development, introspection, and other advantages of the Java system. > Indeed, drawing on my experience with the existing OpenLDAP code base, > it took only a matter of hours to create my first working server, which > I present here. Of course it's still experimental in nature. > > Invocation is similar to the regular C-based slapd, and it accepts all > of the same arguments and reads all of the same config settings. In > addition, the first commandline argument must be the name of the directory > where slapd resides, so that the java app can locate the config files, > schema, etc. > > E.g. for a typical OpenLDAP installation in /usr/local you would run > java jslapd /usr/local/libexec -h ldap://:389 > > A small shell script has been provided to simplify this invocation. Howard, many thanks for the contribution. I haven't stressed it yet intensively, but at a first glance it seems to be as performing as the latest 2.4. Will this be released in 2.4, or do we need to wait until 2.5 (what about making it 3.0?). 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#5440) back-meta opens too many connections in case of error
by ali.pouya＠free.fr 01 Apr '08

01 Apr '08

Hi Pierangelo; When trying to reproduce the problem with test035 material I found a problem in my own JAVA code ! There is no such problem in back-meta :-) Sorry for misreporting and thanks for your help. The issue is to be closed. Best regards Ali Pierangelo Masarati a écrit : > ali.pouya(a)free.fr wrote: > >> I precise that The behaviour is not the same if the client binds with >> rootdn. > > I've committed a fix that removes dangling connections as the rootdn; > I have been unable to reproduce the issue with regular users. Please > provide more useful info in order to track the issue (slapd.conf, LDIF > and requests). > > 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#5449) X-PIGLATIN password hashing functions
by mbackes＠symas.com 31 Mar '08

31 Mar '08

Full_Name: Matthew Backes Version: 2.x OS: any URL: http://www.symas.net/~lucca/piglatin-patch.txt Submission from: (NULL) (76.88.99.93) In order to improve the variety of security options available to LDAP administrators, I am submitting an additional password hashing method for liblutil. This patch implements the {X-PIGLATIN} hash, e.g.: $ slappasswd -s feep -h '{X-PIGLATIN}' {X-PIGLATIN}eepfay The standard with -yay variation for leading values is used, as described in http://en.wikipedia.org/wiki/Pig_latin y is considered a vowel unless it is the leading char. The patch will need additional review for EBCDIC support. This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Matthew Backes <mbackes(a)symas.com>. I have not assigned rights and/or interest in this work to any party. diff -u -r1.107 passwd.c --- passwd.c 7 Jan 2008 23:20:06 -0000 1.107 +++ passwd.c 1 Apr 2008 03:13:13 -0000 @@ -119,6 +119,9 @@ #endif #endif +static LUTIL_PASSWD_CHK_FUNC chk_piglatin; +static LUTIL_PASSWD_HASH_FUNC hash_piglatin; + /* password hash routines */ #ifdef SLAPD_CLEARTEXT @@ -154,6 +157,7 @@ { BER_BVC("{CLEARTEXT}"), NULL, hash_clear }, #endif + { BER_BVC("{X-PIGLATIN}"), chk_piglatin, hash_piglatin }, { BER_BVNULL, NULL, NULL } }; @@ -1127,3 +1131,78 @@ } #endif +static int +chk_piglatin( + const struct berval *sc, + const struct berval * passwd, + const struct berval * cred, + const char **text ) +{ + struct berval credhash; + int rc; + + rc = hash_piglatin( sc, cred, &credhash, NULL ); + if( rc != LUTIL_PASSWD_OK ) return rc; + + rc = passwd->bv_len == credhash.bv_len + && memcmp( passwd->bv_val, + credhash.bv_val, + credhash.bv_len ) == 0 ? + LUTIL_PASSWD_ERR : LUTIL_PASSWD_OK; + + ber_memfree( credhash.bv_val ); + return rc; +} + +/* Implement {X-PIGLATIN} + * See http://en.wikipedia.org/wiki/Pig_latin + * -yay variation for leading vowels used + * y is considered a vowel unless it is the leading char + */ + +static int +hash_piglatin( + const struct berval *scheme, + const struct berval *passwd, + struct berval *hash, + const char **text ) +{ + struct berval digest; + int c, rc, first_vowel = 0; + + hash->bv_len = scheme->bv_len + passwd->bv_len + 2; + hash->bv_val = ber_memalloc( scheme->bv_len + passwd->bv_len + 4 ); + if( !hash->bv_val ) return LUTIL_PASSWD_ERR; + + for( c = 0; c < passwd->bv_len; ++c ) { + switch( passwd->bv_val[c] & -33 ) { + case 'Y': + if( c==0 ) break; + case 'A': + case 'E': + case 'I': + case 'O': + case 'U': + first_vowel = c; + goto got_vowel; + } + } + +got_vowel: + if( first_vowel ) { + char * pos = hash->bv_val; + pos += sprintf( pos, "%s%s", + scheme->bv_val, + passwd->bv_val+first_vowel ); + snprintf( pos, first_vowel+1, "%s", + passwd->bv_val ); + pos += first_vowel; + sprintf( pos, "ay" ); + } else { + sprintf( hash->bv_val, "%s%syay", + scheme->bv_val, passwd->bv_val ); + hash->bv_len += 1; + } + + return LUTIL_PASSWD_OK; +} Also available from the provided URL.

1 0

(ITS#5448) CONTRIB: Java slapd
by hyc＠OpenLDAP.org 31 Mar '08

31 Mar '08

Full_Name: Howard Chu Version: 0.0.1 OS: URL: ftp://ftp.openldap.org/incoming/jslapd.tgz Submission from: (NULL) (76.91.220.157) Submitted by: hyc Given the increasing popularity of Java, I decided it was time that the OpenLDAP Project had its own Java implementation of an LDAP server. It gave me a good opportunity to explore all of the benefits of rapid development, introspection, and other advantages of the Java system. Indeed, drawing on my experience with the existing OpenLDAP code base, it took only a matter of hours to create my first working server, which I present here. Of course it's still experimental in nature. Invocation is similar to the regular C-based slapd, and it accepts all of the same arguments and reads all of the same config settings. In addition, the first commandline argument must be the name of the directory where slapd resides, so that the java app can locate the config files, schema, etc. E.g. for a typical OpenLDAP installation in /usr/local you would run java jslapd /usr/local/libexec -h ldap://:389 A small shell script has been provided to simplify this invocation.

1 0

Re: (ITS#5444) slapd seg. fault using mulitmirrored mode
by ando＠sys-net.it 31 Mar '08

31 Mar '08

hyc(a)symas.com wrote: > ando(a)sys-net.it wrote: >> ando(a)sys-net.it wrote: >>> mohel(a)web.de wrote: >>> >>>> The above log was generated using the test050 script just adding a line which >>>> enters information also to a second server. Perhaps this test would also make >>>> sense for further releases. >>> Can you please post the modification to the script? >> Never mind, I could reproduce it. It seems to be a duplicate of >> ITS#5437. What actually happens is that if modifications are applied to >> all three servers, those applied to consumers do not persist, nor get >> replicated; on the contrary, the consumers crash later on as described >> in ITS#5437. > > #5437? What you're talking about doesn't seem to match any text in ITS#5437. Well, sorry for not providing more details, I was going to investigate it a little bit more but I had to leave. The crash to me occurs in syncprov_done_ctrl(), as indicated in ITS#5437. What happens is that syncprov_done_ctrl() with an invalid cookie (unset; clearing it in syncprov_search_response(), as suggested in ITS#5437 leads to the behavior I described (writes to consumers are simply ignored, don't persist in the consumers and are not replicated). To reproduce, add something to a consumer close to the end of test050, before killing the servers, and wait a little bit to let things proceed to the crash. 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#5444) slapd seg. fault using mulitmirrored mode
by hyc＠symas.com 31 Mar '08

31 Mar '08

ando(a)sys-net.it wrote: > ando(a)sys-net.it wrote: >> mohel(a)web.de wrote: >> >>> The above log was generated using the test050 script just adding a line which >>> enters information also to a second server. Perhaps this test would also make >>> sense for further releases. >> Can you please post the modification to the script? > > Never mind, I could reproduce it. It seems to be a duplicate of > ITS#5437. What actually happens is that if modifications are applied to > all three servers, those applied to consumers do not persist, nor get > replicated; on the contrary, the consumers crash later on as described > in ITS#5437. #5437? What you're talking about doesn't seem to match any text in ITS#5437. -- -- 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#5442) slapd_rq not locked before use bugfix
by hyc＠symas.com 31 Mar '08

31 Mar '08

Rein Tollevik wrote: > On Sun, 30 Mar 2008, hyc(a)symas.com wrote: > >> rein(a)tollevik.no wrote: >>> On Sat, 29 Mar 2008, ando(a)sys-net.it wrote: >>>> rein(a)basefarm.no wrote: > >>>>> I was seeing random failures of the test050-syncrepl-multimaster test. One of >>>>> the failures was that it went into a tight loop traversing a circular runqueue >>>>> it had managed to create in slapd_rq.task_list. It seems as this was caused by >>>>> missing mutex locks around accesses to slapd_rq, which the patch uploaded to >>>>> ftp://ftp.openldap.org/incoming/slapd_rq_lock.patch fixes. >>>>> >>>>> Before I applied this patch the test failed after being run a few times, with it >>>>> it has now passed 100 times and is still counting. >>>> locks in back-bdb/config.c should be pointless, as modifications to the >>>> configuration should only occur while all threads are paused. The rest >>>> makes sort of sense, but I'd leave it to Howard. >> Ignoring the ITS#5403 changes, I don't see anything here that isn't >> config-related, therefore it's all running single-threaded. > > Now that the configuration can be changed dynamically (as this test does) > I find it a bit odd that the config stuff should always be running > single-threaded. But there is obviously much I don't know about the > internals of slapd. This was discussed at the 2003 OpenLDAP Developers' Day. http://www.openldap.org/conf/odd-wien-2003/proceedings.html Page 7 of my slides touched on it. It's also mentioned again here http://www.openldap.org/lists/openldap-devel/200505/msg00062.html The main point is that the original config stuff assumed that it was only executing during slapd startup, and single-threaded. Putting locks around all of the potential configurable value accesses would have been too much work, so the decision was made to force slapd to be single-threaded whenever writing to the config. I'm guessing that what's happening here is just a broken assumption - suspending the thread pool doesn't in fact freeze everything in slapd. In particular, the slapd listener thread may still wake up for a select() timeout to handle the slapd runqueue. Even though no tasks submitted as a result of this will execute (because they'll just get queued into the suspended thread pool) the runqueue itself is still being manipulated. Given that explanation, your patches make sense. -- -- 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#5439) back-bdb race condition
by quanah＠zimbra.com 31 Mar '08

31 Mar '08

--On Monday, March 31, 2008 6:27 PM +0000 rein(a)basefarm.no wrote: > We did see segmentation faults both Friday and Monday (not very much > going on during the weekend..), but so far those appear to be related to > ITS#5445. A slapd and db_checkpoint (run out of cron) deadlock which I > hope is due to the BerkeleyDB bug mentioned in ITS#5391 has also > occurred, so I'll upgrade from 4.6.18 to 4.6.21.1 to see if that problem > goes away. Why do you run db_checkpoint out of cron? Slapd will already take care of checkpointing the database for you using the "checkpoint" directive... --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

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