openldap-bugs

openldap-bugs@openldap.org

20960 discussions

Re: ITS#5112
by rhafer＠suse.de 20 Sep '07

20 Sep '07

This should now be fixed in HEAD. The changer however cause test020-proxycache to fail currently. But that seems to be related to the ITS#5113 issue (the cache is used before it is completely populated). Working on that next. -- Ralf

1 0

Re: (ITS#4860) Sets' enhancement
by raphael.ouazana＠linagora.com 20 Sep '07

20 Sep '07

Hi, Le Jeu 13 septembre 2007 22:47, ando(a)sys-net.it a écrit : > Should be fixed now in HEAD/re24/re23. Please test. p. Thank you for that and for the various fixes (/-*, documentation). We are going to test your fixes as soon as possible. Regards, Raphael Ouazana.

1 0

Re: (ITS#5146) slapo-ppolicy
by hyc＠symas.com 19 Sep '07

19 Sep '07

tonni(a)hetnet.nl wrote: > I'd like to see ppolicy refuse to accept a multi-value userPassword. Agreed, this problem is already highlighted in the current code. (See the FIXME comment in ppolicy.c around line 1556.) We just haven't decided on a proper solution yet. It appears that the RFC3112 authPassword suffers from the same problem. If I were to design all of this today I would have made these attributes single-valued, and used attribute tags to specify the password hash mechanism. E.g., authPassword;crypt: 0123456789abcd authPassword;sha1: xxxxxxxxxxxxxx Since the Password Policy draft *does* include provisions for applying policies to multiple password attributes, then this problem would no longer exist. Of course now that userPassword and authPassword already exist, all the good attribute names are already gone. ;) -- -- 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#5146) slapo-ppolicy
by tonni＠hetnet.nl 19 Sep '07

19 Sep '07

Full_Name: Tony Earnshaw Version: 2.3.38 OS: Red Hat derived: Fedora FC6 and RHEL5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.10.163.78) I'm adopting ppolicy for the enterprise site I manage as far as OpenLDAP is concerned. It's running on RHEL5, has a 2.3 provider and 3 delta-syncrepl consumers. Main application software is Samba PDC (100+ Windows XP users), LTSP (Linux Terminal Server Project) for around 80 terminals and email (smtp and IMAP). Up to now, after 4 years, the site's password policy has been to force all users to accept new passwords that Admin generates for them with apg (good passwords). Each uid and password is (thanks to OpenLDAP), valid for every service offered by the site. We are going to change our password policy to that of Semersheim and force users to change their own policy at regular intervals, according to slapo-ppolicy. I'm doing lab tests on my own Fedora FC6 machine prior to implementing. Everything OpenLDAP supplies works, no complaint. Even Windows passwords get changed in sync, if the correct interface (in our case pam) is chosen. That's not the subject of this ITS. My complaint is, that by changing our ACLs to allow users write access to necessary attributes, ppolicy opens up a can of worms. Specifically, the attribute userPassword is multi value. That is, given a suitable utility (examples are phpldapadmin and gq), a user with write rights can enter multiple passwords for his account. Each of these extra passwords *works* and the superfluous passwords bypass ppolicy's pwdHistory, never get recorded, are always valid. IOTW, a user who has many passwords can validate with any of them and none but one is subject to ppolicy pwdHistory constraints. I've temporarily solved this by patching servers/slapd/schema_prep.c such that userPassword becomes SINGLE-VALUE. But this is obviously not the way to go. If the rfcs decree that userPassword has to be multi-value, then it has to be multi-value, however downright *STUPID* the rfc. Someone else has to change that. I'd like to see ppolicy refuse to accept a multi-value userPassword. "But that's not part of Semersheim", you enjoinder. Well, eff Semersheim, that's a draft, accepting multi-value userPassword is (somewhere) an rfc.

1 0

(ITS#5145) Contrib: Automatic groups overlay
by michal.szulczynski＠altkom.pl 19 Sep '07

19 Sep '07

Full_Name: Michał Szulczyński Version: OS: URL: ftp://ftp.openldap.org/incoming/michal.szulczynski-autogroup-070919.tar.gz Submission from: (NULL) (87.204.26.249) The autogroup overlay allows automated updates of group membership which meet the requirements of any filter contained in the group. The filters are build from the LDAP URI-valued attributes. Any time an object is added/deleated/updated, it is tested for compilance with the filters, and its membership is accordingly updated. For searches and compares it behaves like a static group.

1 0

imporvement to slapo-constraint (ITS#4987)
by manu＠netbsd.org 19 Sep '07

19 Sep '07

Here are improvements: 1) Instead of matching against an individual attribute, match against a set of values returned by an LDAP URI: ftp://ftp.openldap.org/incoming/manu-070918.patch 2) a man page for slapo-constraint(5) ftp://ftp.openldap.org/incoming/manu-pkg-070919.tgz -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

Re: (ITS#5077) syncrepl.add_cmp() infinite loop on swapped values
by donn＠u.washington.edu 19 Sep '07

19 Sep '07

On Sep 18, 2007, at 4:35 PM, Howard Chu wrote: > donn(a)u.washington.edu wrote: >> On Aug 23, 2007, at 2:56 PM, Howard Chu wrote: >> [ ... re attribute value matching ... ] >>> The only way to do this right, without dying on an O(n^2) >>> algorithm, is to sort both arrays first and then walk through >>> them in order as the original code did. If you want to submit >>> such a patch, please do. I don't have a lot of time to focus on >>> this at the moment. >> I did look at this, and the attached patch is what I came up with, >> relative to HEAD 1.356. I have tested it, but unfortunately the > > Thanks but I already went ahead with a different fix for this since > I didn't hear back from you. Yes, I know, I understand that to be the O(n^2) option you mention above. It's certainly the simplest way. Donn Cave, donn(a)u.washington.edu

1 0

Re: (ITS#5077) syncrepl.add_cmp() infinite loop on swapped values
by hyc＠symas.com 19 Sep '07

19 Sep '07

donn(a)u.washington.edu wrote: > --Apple-Mail-4--750948447 > Content-Transfer-Encoding: 7bit > Content-Type: text/plain; > charset=US-ASCII; > delsp=yes; > format=flowed > > > On Aug 23, 2007, at 2:56 PM, Howard Chu wrote: > [ ... re attribute value matching ... ] >> The only way to do this right, without dying on an O(n^2) >> algorithm, is to sort both arrays first and then walk through them >> in order as the original code did. If you want to submit such a >> patch, please do. I don't have a lot of time to focus on this at >> the moment. > > I did look at this, and the attached patch is what I came up with, > relative to HEAD 1.356. I have tested it, but unfortunately the Thanks but I already went ahead with a different fix for this since I didn't hear back from you. -- -- 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#5077) syncrepl.add_cmp() infinite loop on swapped values
by donn＠u.washington.edu 19 Sep '07

19 Sep '07

--Apple-Mail-4--750948447 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Aug 23, 2007, at 2:56 PM, Howard Chu wrote: [ ... re attribute value matching ... ] > > The only way to do this right, without dying on an O(n^2) > algorithm, is to sort both arrays first and then walk through them > in order as the original code did. If you want to submit such a > patch, please do. I don't have a lot of time to focus on this at > the moment. I did look at this, and the attached patch is what I came up with, relative to HEAD 1.356. I have tested it, but unfortunately the results are confounded by other problems - a crash (syncprov thread queue entry so->s_qtask wasn't in slapd_rq, and some pointer values in the former structure were 0x30303030), and in the end the replica was missing a lot of attribute deletions. Wouldn't think either was related to attr_cmp(), but I am out of time to look at these problems and keep trying to demonstrate a 100% successful syncrepl replication. I didn't sort the arrays. I tried that (quicksort algorithm), and it was very expensive. If there's reason to hope that the old and new values will be mostly in the same order, then it is much cheaper in this case to start with a simple pairwise walk through, as in the older code, and then clean up with a full O(n^2) match on what's left. The implementation is also simpler. Actual performance depends on the data, but with the data I used for tests of the algorithms, I found that this approach outperforms the original 2.4.4 implementation, in terms of bvmatch counts. That's because the 2.4.4 needed to look ahead through the rest of the value array in a couple of places in the loop. Performance will be worst where many values are changed, i.e., many adds and deletes - many adds and few deletes, or vice versa, will be significantly faster. I think this is good for most real world situations. I restored variable names from 2.4.4 because they returned to their original usage, likewise with the sml_values handling, and dedicated a variable to the modtail logic at the end of attr_cmp(). I haven't looked into it, but happened to notice just this afternoon a comment in dn_callback(): "We assume that attributes are saved in the same order in the remote and local databases. So ..." Donn Cave, donn(a)u.washington.edu --Apple-Mail-4--750948447 Content-Transfer-Encoding: 7bit Content-Type: application/octet-stream; x-unix-mode=0644; name=syncrepl.c Content-Disposition: attachment; filename=syncrepl.c --- servers/slapd/syncrepl.c.orig 2007-09-18 15:10:52.000000000 -0700 +++ servers/slapd/syncrepl.c 2007-09-18 15:57:33.000000000 -0700 @@ -2673,17 +2673,98 @@ return rc; } +/* Remove null elements. */ +static int +nonulls( struct berval **a, int na ) +{ + int i, n; + for ( i = n = 0; i < na; ++i ) { + if ( a[i] ) { + if ( i > n ) + a[n] = a[i]; + ++n; + } + } + return n; +} + +/* +** Secondary difference: remove any remaining matching elements, +** by brute force M*N comparison. +*/ +static void +ixpurge( struct berval **iva, int niva, int *nivap, + struct berval **ivb, int nivb, int *nivbp ) +{ + int ia, ib; + for ( ia = 0; ia < niva; ++ia ) { + for ( ib = 0; ib < nivb; ++ib ) { + if ( ivb[ib] && bvmatch( iva[ia], ivb[ib] ) ) { + iva[ia] = 0; + ivb[ib] = 0; + break; + } + } + } + *nivap = nonulls( iva, niva ); + *nivbp = nonulls( ivb, nivb ); +} + +/* +** Compare two lists of berval strings that are supposed to be in +** similar order, and return list of indices to old (delete) and +** new (add) elements of the respective lists. If of significantly +** different sizes, the smaller should be first for optimal performance. +*/ +static void +diff1( + struct berval *bva, + int na, + struct berval *bvb, + int nb, + struct berval **dva, + int *ndvap, + struct berval **dvb, + int *ndvbp +) +{ + int ia, ib, ib0, ndva, ndvb, ndvar, ndvbr; + ndva = ndvb = 0; + for ( ia = ib0 = 0; ia < na; ++ia ) { + /* Find a/b match, starting from last b anchor. */ + for ( ib = ib0; ib < nb && !bvmatch( &bva[ia], &bvb[ib] ); ++ib ) + ; + if ( ib < nb ) { + /* Found. Record non-matching b's, reset anchor. */ + for ( ; ib0 < ib; ++ib0 ) + dvb[ndvb++] = &bvb[ib0]; + ++ib0; + } else { + /* Not found, record non-matching a. */ + dva[ndva++] = &bva[ia]; + } + } + /* Record remaining unmatched b's. */ + for ( ; ib0 < nb; ++ib0 ) + dvb[ndvb++] = &bvb[ib0]; + /* Clean up spurious non-matches, in case order assumptions invalid. */ + ixpurge( dva, ndva, &ndvar, dvb, ndvb, &ndvbr ); + *ndvap = ndvar; + *ndvbp = ndvbr; +} + static void attr_cmp( Operation *op, Attribute *old, Attribute *new, Modifications ***mret, Modifications ***mcur ) { - int i, j; + int tails; + int i; Modifications *mod, **modtail; modtail = *mret; if ( old ) { - int n, o, nn, no; + int n, o, a, d; struct berval **adds, **dels; /* count old and new */ for ( o=0; old->a_vals[o].bv_val; o++ ) ; @@ -2692,105 +2773,83 @@ /* there MUST be both old and new values */ assert( o != 0 ); assert( n != 0 ); - j = 0; adds = op->o_tmpalloc( sizeof(struct berval *) * n, op->o_tmpmemctx ); dels = op->o_tmpalloc( sizeof(struct berval *) * o, op->o_tmpmemctx ); - for ( i=0; i<o; i++ ) dels[i] = &old->a_vals[i]; - for ( i=0; i<n; i++ ) adds[i] = &new->a_vals[i]; - - nn = n; no = o; - - for ( i=0; i<o; i++ ) { - for ( j=0; j<n; j++ ) { - if ( !adds[j] ) - continue; - if ( bvmatch( dels[i], adds[j] ) ) { - no--; - nn--; - adds[j] = NULL; - dels[i] = NULL; - break; - } - } - } + if ( o > n ) + diff1( new->a_vals, n, old->a_vals, o, adds, &a, dels, &d ); + else + diff1( old->a_vals, o, new->a_vals, n, dels, &d, adds, &a ); + tails = 0; - i = j; /* all old values were deleted, just use the replace op */ - if ( no == o ) { - i = j-1; - } else if ( no ) { + if ( d == o ) { + tails = 1; + } else if ( d ) { /* delete some values */ mod = ch_malloc( sizeof( Modifications ) ); mod->sml_op = LDAP_MOD_DELETE; mod->sml_flags = 0; mod->sml_desc = old->a_desc; mod->sml_type = mod->sml_desc->ad_cname; - mod->sml_values = ch_malloc( ( no + 1 ) * sizeof(struct berval) ); + mod->sml_values = ch_malloc( ( d + 1 ) * sizeof(struct berval) ); if ( old->a_vals != old->a_nvals ) { - mod->sml_nvalues = ch_malloc( ( no + 1 ) * sizeof(struct berval) ); + mod->sml_nvalues = ch_malloc( ( d + 1 ) * sizeof(struct berval) ); } else { mod->sml_nvalues = NULL; } - j = 0; - for ( i = 0; i < o; i++ ) { - if ( !dels[i] ) continue; - ber_dupbv( &mod->sml_values[j], &old->a_vals[i] ); + for ( i = 0; i < d; i++ ) { + ber_dupbv( &mod->sml_values[i], dels[i] ); if ( mod->sml_nvalues ) { - ber_dupbv( &mod->sml_nvalues[j], &old->a_nvals[i] ); + ber_dupbv( &mod->sml_nvalues[i], dels[i] ); } - j++; } - BER_BVZERO( &mod->sml_values[j] ); + BER_BVZERO( &mod->sml_values[i] ); if ( mod->sml_nvalues ) { - BER_BVZERO( &mod->sml_nvalues[j] ); + BER_BVZERO( &mod->sml_nvalues[i] ); } *modtail = mod; modtail = &mod->sml_next; - i = j; + tails = 0; } op->o_tmpfree( dels, op->o_tmpmemctx ); /* some values were added */ - if ( nn && no < o ) { + if ( a && d < o ) { mod = ch_malloc( sizeof( Modifications ) ); mod->sml_op = LDAP_MOD_ADD; mod->sml_flags = 0; mod->sml_desc = old->a_desc; mod->sml_type = mod->sml_desc->ad_cname; - mod->sml_values = ch_malloc( ( nn + 1 ) * sizeof(struct berval) ); + mod->sml_values = ch_malloc( ( a + 1 ) * sizeof(struct berval) ); if ( old->a_vals != old->a_nvals ) { - mod->sml_nvalues = ch_malloc( ( nn + 1 ) * sizeof(struct berval) ); + mod->sml_nvalues = ch_malloc( ( a + 1 ) * sizeof(struct berval) ); } else { mod->sml_nvalues = NULL; } - j = 0; - for ( i = 0; i < n; i++ ) { - if ( !adds[i] ) continue; - ber_dupbv( &mod->sml_values[j], &new->a_vals[i] ); + for ( i = 0; i < a; i++ ) { + ber_dupbv( &mod->sml_values[i], adds[i] ); if ( mod->sml_nvalues ) { - ber_dupbv( &mod->sml_nvalues[j], &new->a_nvals[i] ); + ber_dupbv( &mod->sml_nvalues[i], adds[i] ); } - j++; } - BER_BVZERO( &mod->sml_values[j] ); + BER_BVZERO( &mod->sml_values[i] ); if ( mod->sml_nvalues ) { - BER_BVZERO( &mod->sml_nvalues[j] ); + BER_BVZERO( &mod->sml_nvalues[i] ); } *modtail = mod; modtail = &mod->sml_next; - i = j; + tails = 0; } op->o_tmpfree( adds, op->o_tmpmemctx ); } else { /* new attr, just use the new mod */ - i = 0; - j = 1; + tails = 1; } /* advance to next element */ mod = **mcur; if ( mod ) { - if ( i != j ) { + if ( tails ) { **mcur = mod->sml_next; *modtail = mod; modtail = &mod->sml_next; --Apple-Mail-4--750948447--

1 0

Re: (ITS#5065) out of order ctxcsn from old entryCSN
by donn＠u.washington.edu 19 Sep '07

19 Sep '07

On Aug 29, 2007, at 12:55 AM, Pierangelo Masarati wrote: > >> Old entryCSN values imported into the data from another server, >> can crash >> replicas. > > The ITS reports that this is now fixed in HEAD. I would appreciate > if you > feedback using a fresh HEAD build, since the CSN syntax is now more > thoroughly checked, although it is supposed to allow the old one in > input. I did test this, and it didn't crash. Thanks Donn Cave, donn(a)u.washington.edu

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