- openldap-bugs - openldap.org

Re: (ITS#5942) URI matching of "self" in add_syncrepl is incomplete
by jclarke＠linagora.com 13 Feb '09

13 Feb '09

This is a multi-part message in MIME format. --------------030704040902090700090604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 13.02.2009 14:29, jclarke(a)linagora.com wrote: > On 13.02.2009 01:23, Howard Chu wrote: > >> Jonathan Clarke wrote: >> >>> hyc(a)symas.com wrote: >>> >>>> Ah right. For the serverID code, we're doing a liberal match because >>>> anything >>>> that matches the current name:port is obviously the current server, >>>> and we >>>> want it to be identified as such. >>>> >>>> For syncrepl, we know full well that it may be the current server, >>>> but for >>>> whatever reason you may want to replicate against yourself anyway >>>> (e.g., >>>> against a different baseDN, etc...). >>>> >>> Actually, this comes straight from test049 (config replication). With >>> multimaster config replication, it starts by replicating itself >>> (useless, but necessary for other masters). This problem doesn't appear >>> in the test case, since a variable ($URI1) is used for both the slapd -h >>> $URI1 option, and in the syncrepl provider=$URI1 LDIF. Otherwise it >>> would produce weird results. >>> >> If you want a setup similar to test049, follow what it does. If you >> want to something else, do otherwise. >> > I am following what test049 does. Oops, sorry, I've been mixing 049 and 050 in my head. My bad, this isn't a problem for test049 indeed. Although I am curious as to why test049 creates a syncrepl consumer targeted at itself? Can't quite get my head around it yet, but will keep thinking, with regard to multimaster. --------------030704040902090700090604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#ffffff"> On 13.02.2009 14:29, <a class="moz-txt-link-abbreviated" href="mailto:jclarke@linagora.com">jclarke(a)linagora.com</a> wrote: <blockquote cite="mid:200902131329.n1DDTKF6072656@boole.openldap.org" type="cite"> <pre wrap="">On 13.02.2009 01:23, Howard Chu wrote: </pre> <blockquote type="cite"> <pre wrap="">Jonathan Clarke wrote: </pre> <blockquote type="cite"> <pre wrap=""><a class="moz-txt-link-abbreviated" href="mailto:hyc@symas.com">hyc(a)symas.com</a> wrote: </pre> <blockquote type="cite"> <pre wrap="">Ah right. For the serverID code, we're doing a liberal match because anything that matches the current name:port is obviously the current server, and we want it to be identified as such. For syncrepl, we know full well that it may be the current server, but for whatever reason you may want to replicate against yourself anyway (e.g., against a different baseDN, etc...). </pre> </blockquote> <pre wrap="">Actually, this comes straight from test049 (config replication). With multimaster config replication, it starts by replicating itself (useless, but necessary for other masters). This problem doesn't appear in the test case, since a variable ($URI1) is used for both the slapd -h $URI1 option, and in the syncrepl provider=$URI1 LDIF. Otherwise it would produce weird results. </pre> </blockquote> <pre wrap="">If you want a setup similar to test049, follow what it does. If you want to something else, do otherwise. </pre> </blockquote> <pre wrap="">I am following what test049 does.</pre> </blockquote> Oops, sorry, I've been mixing 049 and 050 in my head. My bad, this isn't a problem for test049 indeed.<br> <br> Although I am curious as to why test049 creates a syncrepl consumer targeted at itself? Can't quite get my head around it yet, but will keep thinking, with regard to multimaster.<br> </body> </html> --------------030704040902090700090604--

1 0

Re: (ITS#5942) URI matching of "self" in add_syncrepl is incomplete
by jclarke＠linagora.com 13 Feb '09

13 Feb '09

On 13.02.2009 01:23, Howard Chu wrote: > Jonathan Clarke wrote: >> hyc(a)symas.com wrote: >>> Ah right. For the serverID code, we're doing a liberal match because >>> anything >>> that matches the current name:port is obviously the current server, >>> and we >>> want it to be identified as such. >>> >>> For syncrepl, we know full well that it may be the current server, >>> but for >>> whatever reason you may want to replicate against yourself anyway >>> (e.g., >>> against a different baseDN, etc...). >> Actually, this comes straight from test049 (config replication). With >> multimaster config replication, it starts by replicating itself >> (useless, but necessary for other masters). This problem doesn't appear >> in the test case, since a variable ($URI1) is used for both the slapd -h >> $URI1 option, and in the syncrepl provider=$URI1 LDIF. Otherwise it >> would produce weird results. > > If you want a setup similar to test049, follow what it does. If you > want to something else, do otherwise. I am following what test049 does. Only difference is test049 starts slapd with "-h $URI1" (with URI1="ldap://localhost:9011/") and I start slapd with no -h option or a slightly different URI. This is quite common, I believe. If you patch the test as follows, it fails: 8<---------------------------------------------------- --- tests/scripts/test049-sync-config 10 Feb 2009 12:29:01 -0000 1.4.2.9 +++ tests/scripts/test049-sync-config 13 Feb 2009 10:11:22 -0000 @@ -112,7 +112,7 @@ $LDAPMODIFY -D cn=config -H $URI1 -y $CO -olcSyncRepl: rid=001 provider=$URI1 binddn="cn=config" bindmethod=simple +olcSyncRepl: rid=001 provider=`echo $URI1 | sed "s/localhost/127.0.0.1/"` binddn="cn=config" bindmethod=simple 8<---------------------------------------------------- Error: 8<---------------------------------------------------- Running ./scripts/test049-sync-config... running defines.sh Starting producer slapd on TCP/IP port 9011... Using ldapsearch to check that producer slapd is running... Inserting syncprov overlay on producer... ldapmodify failed for syncrepl config (10)! 8<---------------------------------------------------- > There are valid reasons to point a syncrepl consumer at the same slapd > (e.g., proxy syncrepl, automatic local backup/mirroring, rewriting a > subtree of a main database, etc.). Using the exhaustive matching that > serverID uses would preclude those cases from working. I see. I understand you don't want to break existing functionality. However, I still feel this is a bug, or at least that you need to "hack" the setup to get things working as expected. Would I be right in assuming that in all the "valid reasons to point a syncrepl consumer at the same slapd" you mention, the syncrepl consumer uses a different base DN than the base DN of the database that the syncrepl consumer is configured on? If so, maybe the exhaustive matching that serverID uses could be used, if and only if those two base DNs are different? Jonathan

1 0

Re: (ITS#5756) 2.4 slapo-pcache only caches first lookup for certain templates
by toby＠inf.ed.ac.uk 13 Feb '09

13 Feb '09

Hi there, I've put this patched version on a small lab of clients (about 23) and on one of them slapd has segfaulted and dumped core. Here's the backtrace: Program terminated with signal 11, Segmentation fault. #0 pcache_filter_cmp (f1=0x8af09f8, f2=0x39) at pcache.c:608 608 switch( f2->f_choice ) { (gdb) bt #0 pcache_filter_cmp (f1=0x8af09f8, f2=0x39) at pcache.c:608 #1 0x08155862 in tavl_insert (root=0x8afe590, data=0x8aefb88, fcmp=0x81399b0 <pcache_query_cmp>, fdup=0x8154700 <avl_dup_error>) at tavl.c:82 #2 0x0813a95d in add_query (op=0x8ae3658, qm=0x8a74cc0, query=0xb55af394, templ=0x8a90f88, why=PC_POSITIVE, wlock=1) at pcache.c:1252 #3 0x0813d7f1 in pcache_op_cleanup (op=0x8ae3658, rs=0xb5eb1148) at pcache.c:2041 #4 0x08076a04 in slap_cleanup_play (op=0x8ae3658, rs=0xb5eb1148) at result.c:341 #5 0x08079a56 in send_ldap_response (op=0x8ae3658, rs=0xb5eb1148) at result.c:522 #6 0x0807aa42 in slap_send_ldap_result (op=0x8ae3658, rs=0xb5eb1148) at result.c:650 #7 0x080f4fef in ldap_back_search (op=0x8ae3658, rs=0xb5eb1148) at search.c:549 #8 0x080cf431 in overlay_op_walk (op=0x8ae3658, rs=0xb5eb1148, which=op_search, oi=0x8a74ff0, on=0x8a750f0) at backover.c:670 #9 0x080cf9ed in over_op_func (op=0x8ae3658, rs=0xb5eb1148, which=op_search) at backover.c:722 #10 0x08069016 in fe_op_search (op=0x8ae3658, rs=0xb5eb1148) at search.c:366 #11 0x0806989b in do_search (op=0x8ae3658, rs=0xb5eb1148) at search.c: 217 #12 0x08066a66 in connection_operation (ctx=0xb5eb1218, arg_v=0x8ae3658) at connection.c:1090 #13 0x08067082 in connection_read_thread (ctx=0xb5eb1218, argv=0xf) at connection.c:1216 #14 0x08159704 in ldap_int_thread_pool_wrapper (xpool=0x8a52f90) at tpool.c:663 #15 0x0064f46b in start_thread () from /lib/libpthread.so.0 #16 0x005a6dbe in clone () from /lib/libc.so.6 This looks a little strange to me... (gdb) p f2->f_choice Cannot access memory at address 0x39 (gdb) up #1 0x08155862 in tavl_insert (root=0x8afe590, data=0x8aefb88, fcmp=0x81399b0 <pcache_query_cmp>, fdup=0x8154700 <avl_dup_error>) at tavl.c:82 82 cmp = fcmp( data, p->avl_data ); (gdb) p p->avl_data $1 = (void *) 0x8af62e0 (gdb) Cheers Toby -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

Re: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by philippe.eychart＠informatique.gov.pf 12 Feb '09

12 Feb '09

This is a multi-part message in MIME format. ------=_NextPart_000_00A9_01C98D2A.7E1AFAD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Here is a first result (patch integration) ... It doen't more remains to write the actual SRV search ... (coming soon) Here is a running log : root@testldap0:/var/log# >syslog root@testldap0:/var/log# grep "^[^#].*ldapsam:" /etc/samba/smb.conf passdb backend = ldapsam:"ldap://ns0 ldap://ns0/ou=profile%2cdc=gov%2cdc=pf??sub?(objectClass=*)?x-dnssrv=dc=gov% 2cdc=pf ldap://newldap/dc=srv%2cdc=gov%2cdc=pf??sub?(objectClass=*)?toto ldap:///dc=srv%2cdc=gov%2cdc=pf??sub??toto" root@testldap0:/var/log# /etc/rc.d/rc.samba restart Starting Samba: /usr/local/samba/sbin/smbd -D /usr/local/samba/sbin/nmbd -D root@testldap0:/var/log# cat syslog Feb 13 01:38:25 testldap0 smbd: the final url is: "ldap://ns0 ldap://ldap1.gov.pf ldap://ldap2.gov.pf ldap://ldap3.gov.pf ldap://newldap/dc=srv%2cdc=gov%2cdc=pf??sub?(objectClass=*)?toto ldap://ldap1.gov.pf ldap://ldap2.gov.pf ldap://ldap3.gov.pf-" -- PE ------=_NextPart_000_00A9_01C98D2A.7E1AFAD0 Content-Type: application/octet-stream; name="open.c.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="open.c.patch" --- openldap-2.4.13/libraries/libldap/open.c 2008-10-31 = 23:23:58.000000000 +0000=0A= +++ openldap-2.4.13/libraries/libldap/open.c 2009-02-13 = 01:30:35.000000000 +0000=0A= @@ -212,19 +212,128 @@=0A= return( ld );=0A= }=0A= =0A= +int=0A= +url_expand_on_srv_search ( char ***result, LDAP_CONST char *url_in, = char *domain )=0A= +{ int rc =3D 0;=0A= +=0A= +if ( (*result =3D ldap_str2charray( "ldap://ldap1.gov.pf = ldap://ldap2.gov.pf ldap://ldap3.gov.pf", " " )) !=3D NULL ) rc =3D 3; = // line to delete ...=0A= +=0A= + // Coming soon ...=0A= +=0A= + return rc;=0A= +}=0A= +=0A= +char *=0A= +expand_dnssrv_definitions ( LDAP_CONST char *url_in )=0A= +{=0A= + char *dom, *s, *dn =3D NULL, **srvSearchResult =3D NULL;=0A= + char **urls =3D NULL, **extentions =3D NULL;=0A= + int i, ii, urlsNb=3D0;=0A= +=0A= + if( url_in =3D=3D NULL ) {=0A= + return NULL;=0A= + }=0A= +=0A= + urls =3D ldap_str2charray( url_in, " " );=0A= +=0A= + while( urls[urlsNb] ) urlsNb++; // How many urls is there ?...=0A= +=0A= + for( i=3D0; (dom=3Durls[i]); i++ ) { // for each URL, search SRV = domain ...=0A= +=0A= + // Search for "x-dnssrv" extention (fifth field) ...=0A= + if ( *(dom =3D (char *)strchrnul( dom, '?' )) !=3D '?' || ! *(++dom) = ) continue;=0A= + if ( *(dom =3D (char *)strchrnul( dom, '?' )) !=3D '?' || ! *(++dom) = ) continue;=0A= + if ( *(dom =3D (char *)strchrnul( dom, '?' )) !=3D '?' || ! *(++dom) = ) continue;=0A= + if ( *(dom =3D (char *)strchrnul( dom, '?' )) !=3D '?' || ! *(++dom) = ) continue;=0A= + extentions =3D ldap_str2charray( dom, "," );=0A= + for ( dom=3DNULL,ii=3D0; extentions[ii]; ii++ ) {=0A= + ldap_pvt_str2lower ( extentions[ii]+1 );=0A= + if ( strncmp( extentions[ii], "x-dnssrv=3D", sizeof ( "x-dnssrv=3D" = )-1) =3D=3D 0 ) {=0A= + dom =3D extentions[ii] + sizeof ( "x-dnssrv=3D" ) - 1;=0A= + break;=0A= + } }=0A= +=0A= + // Search for dn =3D=3D "dc=3D.*[,dc=3D.*]*" - only in case there was = not any "x-dnssrv" extension ...=0A= + if ( ! dom ) { dom=3Durls[i];=0A= + if ( *(dom =3D (char *)strchrnul( dom, '/' )) !=3D '/' = || !strncmp ( dom, "///dc=3D", 6 ) =3D=3D 0 ) continue;=0A= + dom=3Ddn=3D (char *) LDAP_STRDUP ( dom+3 );=0A= + if ( dom ) *(char *)strchrnul( dom, '?' ) =3D '\0';=0A= + }=0A= + =0A= + // Does dom realy look like a domain name (if a dn format is = detected) ?...=0A= + if ( dom && strncmp(dom, "dc=3D", 3) =3D=3D 0 ) // It's effectively a = dn definition (not just a domaine name) ?...=0A= + for ( s=3Ddom+3; *s; s++ ) // Nothing else than "dc=3D" in the = string ?...=0A= + if ( *s =3D=3D '=3D' && *(s-1) !=3D 'c' && *(s-2) !=3D 'd') {=0A= + dom =3D NULL; // never mind, a next time !...=0A= + break; =0A= + }=0A= +=0A= + // Replace the current url with the result of the SRV search ...=0A= + if ( dom ) {=0A= + int rc =3D url_expand_on_srv_search ( &srvSearchResult, urls[i], dom = );=0A= +=0A= + if ( rc > 0 ) { // Substitution (must keep the initial order of = the urls) ...=0A= + char **u, **result =3D srvSearchResult;=0A= + if ( (u =3D (char **)LDAP_MALLOC( (urlsNb + rc) * sizeof(char *) )) = ) {=0A= + for ( ii=3DurlsNb + rc; ii; ) u[--ii] =3D NULL;=0A= + while ( ii<i ) {=0A= + u[ii] =3D urls[ii];=0A= + ii++;=0A= + } while ( ii<i+rc && rc ) { // replace url[i] with url(s) = resulting from the SRV search ...=0A= + u[ii] =3D *result++;=0A= + ii++;=0A= + } while ( urls[ii-rc+1] && rc ) {=0A= + u[ii] =3D urls[ii-rc+1];=0A= + ii++;=0A= + } u[ii] =3D NULL;=0A= + LDAP_FREE ( urls );=0A= + urls =3D u;=0A= + rc--; i +=3D rc; urlsNb +=3D rc;=0A= + }=0A= + LDAP_FREE ( srvSearchResult );=0A= + } }=0A= +=0A= + // it's done for the current url ...=0A= + LDAP_FREE( dn );=0A= + ldap_charray_free( extentions );=0A= + }=0A= +=0A= + // last job : to construct the result string ...=0A= + for ( i=3D0; urls[i]; i++ ) {=0A= + urlsNb +=3D strlen( urls[i] );=0A= + urlsNb++; // for urls separator: ' ' ...=0A= + } if ( (s =3D (char *)LDAP_MALLOC( ++urlsNb )) !=3D NULL ) {=0A= + for ( *s=3D'\0',i=3D0; urls[i]; i++ )=0A= + sprintf ( &s[strlen(s)], "%s ", urls[i] );=0A= + s[strlen(s)-1] =3D '\0'; // delete last ' ' ...=0A= + }=0A= +=0A= + ldap_charray_free( urls );=0A= +=0A= + // bye ...=0A= + return ( s );=0A= +}=0A= +=0A= =0A= int=0A= -ldap_initialize( LDAP **ldp, LDAP_CONST char *url )=0A= +ldap_initialize( LDAP **ldp, LDAP_CONST char *url_in )=0A= {=0A= int rc;=0A= LDAP *ld;=0A= + char *url;=0A= =0A= *ldp =3D NULL;=0A= rc =3D ldap_create(&ld);=0A= if ( rc !=3D LDAP_SUCCESS )=0A= return rc;=0A= =0A= - if (url !=3D NULL) {=0A= + if (url_in !=3D NULL) {=0A= + url =3D expand_dnssrv_definitions ( url_in );=0A= + if ( url =3D=3D NULL ) {=0A= + return LDAP_URL_ERR_MEM;=0A= + }=0A= +syslog ( 3, "the final url is: \"%s-\"", url ); // to delete ...=0A= +=0A= rc =3D ldap_set_option(ld, LDAP_OPT_URI, url);=0A= if ( rc !=3D LDAP_SUCCESS ) {=0A= ldap_ld_free(ld, 1, NULL, NULL);=0A= @@ -234,6 +343,7 @@=0A= if (ldap_is_ldapc_url(url))=0A= LDAP_IS_UDP(ld) =3D 1;=0A= #endif=0A= + LDAP_FREE( url );=0A= }=0A= =0A= *ldp =3D ld;=0A= ------=_NextPart_000_00A9_01C98D2A.7E1AFAD0--

1 0

Re: (ITS#5942) URI matching of "self" in add_syncrepl is incomplete
by hyc＠symas.com 12 Feb '09

12 Feb '09

Jonathan Clarke wrote: > hyc(a)symas.com wrote: >> Ah right. For the serverID code, we're doing a liberal match because anything >> that matches the current name:port is obviously the current server, and we >> want it to be identified as such. >> >> For syncrepl, we know full well that it may be the current server, but for >> whatever reason you may want to replicate against yourself anyway (e.g., >> against a different baseDN, etc...). > Actually, this comes straight from test049 (config replication). With > multimaster config replication, it starts by replicating itself > (useless, but necessary for other masters). This problem doesn't appear > in the test case, since a variable ($URI1) is used for both the slapd -h > $URI1 option, and in the syncrepl provider=$URI1 LDIF. Otherwise it > would produce weird results. If you want a setup similar to test049, follow what it does. If you want to something else, do otherwise. There are valid reasons to point a syncrepl consumer at the same slapd (e.g., proxy syncrepl, automatic local backup/mirroring, rewriting a subtree of a main database, etc.). Using the exhaustive matching that serverID uses would preclude those cases from working. As usual, when you're configuring a server, you have to pay attention to what you're doing and what effect you want to accomplish. -- -- 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#5940) crash in slapo-rwm when modifying olcRwmRewrite
by ando＠sys-net.it 12 Feb '09

12 Feb '09

ando(a)sys-net.it wrote: > Also, please note that modifications to olcRwmRewrite is not allowed, > unless consisting in a full replace without {} idxes. The operation you > were trying, More about this: now slapo-rwm supports add/delete/modify olcRwmRewrite values (in a far from optimal manner). 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5940) crash in slapo-rwm when modifying olcRwmRewrite
by ando＠sys-net.it 12 Feb '09

12 Feb '09

ando(a)sys-net.it wrote: > Please forget my previous posting. Your issue should now be solved in > HEAD. Please test. p. Also, please note that modifications to olcRwmRewrite is not allowed, unless consisting in a full replace without {} idxes. The operation you were trying, 8<---------------------------- dn: olcOverlay={0}rwm,olcDatabase={1}ldap,cn=config changeType: modify replace: olcRwmRewrite olcRwmRewrite: {0}rwm-suffixmassage "o=proxy" "dc=demo,dc=lan" 8<---------------------------- is not allowed. This is allowed, though: 8<---------------------------- dn: olcOverlay={0}rwm,olcDatabase={1}ldap,cn=config changeType: modify replace: olcRwmRewrite olcRwmRewrite: rwm-suffixmassage "o=proxy" "dc=demo,dc=lan" 8<---------------------------- note the missing {0}. Support for renumbering of olcRwmRewrite could be introduced by removing rewrite info and regenerating it from the saved values. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5942) URI matching of "self" in add_syncrepl is incomplete
by jclarke＠linagora.com 12 Feb '09

12 Feb '09

hyc(a)symas.com wrote: > Howard Chu wrote: > >> hyc(a)symas.com wrote: >> >>> jclarke(a)linagora.com wrote: >>> >>>> I saw the comment in the code that clarifies this behaviour. However, it's a >>>> surprising behaviour, and I think there is code to parse this kind of thing in >>>> the serverID detection now. Maybe it could be reused? >>>> >> Oops, never mind. I was thinking of the serverID code, and you're talking >> about the syncrepl code. >> >> I'll have to think a bit about why the two aren't behaving identically; >> probably they should both use the same code. >> >> > Ah right. For the serverID code, we're doing a liberal match because anything > that matches the current name:port is obviously the current server, and we > want it to be identified as such. > > For syncrepl, we know full well that it may be the current server, but for > whatever reason you may want to replicate against yourself anyway (e.g., > against a different baseDN, etc...). > Actually, this comes straight from test049 (config replication). With multimaster config replication, it starts by replicating itself (useless, but necessary for other masters). This problem doesn't appear in the test case, since a variable ($URI1) is used for both the slapd -h $URI1 option, and in the syncrepl provider=$URI1 LDIF. Otherwise it would produce weird results. Jon

1 0

Re: (ITS#5940) crash in slapo-rwm when modifying olcRwmRewrite
by ando＠sys-net.it 12 Feb '09

12 Feb '09

jclarke(a)linagora.com wrote: > Given a simple setup involving back-ldap with slapo-rwm on top, modifying the > attribute "olcRwmRewrite" causes a crash. This seems to happen both while > modifying an existing value, or when deleting one. Please forget my previous posting. Your issue should now be solved in HEAD. Please test. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5943) back-relay does not recognize when would call self
by ando＠sys-net.it 12 Feb '09

12 Feb '09

ando(a)sys-net.it wrote: > Simply comparing the BackendDB pointers of the operation and of the operation's > DN does not detect when back-relay would call self, possibly resulting in > endless loop. should be fixed in HEAD. Please test. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5943) back-relay does not recognize when would call self
by ando＠sys-net.it 12 Feb '09

12 Feb '09

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando Simply comparing the BackendDB pointers of the operation and of the operation's DN does not detect when back-relay would call self, possibly resulting in endless loop. p.

1 0

Re: (ITS#5942) URI matching of "self" in add_syncrepl is incomplete
by jclarke＠linagora.com 12 Feb '09

12 Feb '09

Le Jeu 12 février 2009 20:41, Howard Chu a écrit : > jclarke(a)linagora.com wrote: >> Full_Name: Jonathan Clarke >> Version: RE24 >> OS: irrelevant >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (213.41.243.192) >> >> >> Hi, >> >> When adding a syncrepl config, the function add_syncrepl performs a >> "check if >> URL points to current server". This check is based on an exact match >> between the >> provider parameter from the syncrepl config line, and the URIs given to >> slapd on >> startup. >> >> If this doesn't match when it should, the database is marked as a >> shadow, and >> all following updates fail with "shadow context; no update refs". This >> is quite >> a pain when it happens on cn=config :) >> >> There are multiple cases when this happens: >> 1) If no specific URI was specified on launch (no -h option) >> 2) Port numbers are explicitly specified or not (":389") >> 3) Trailing slash (for example "ldap://1.2.3.4" != "ldap://1.2.3.4/") >> 4) IP is specified rather than DNS name ("ldap://localhost" != >> "ldap://127.0.0.1") >> >> I saw the comment in the code that clarifies this behaviour. However, >> it's a >> surprising behaviour, and I think there is code to parse this kind of >> thing in >> the serverID detection now. Maybe it could be reused? >> >> Otherwise, we should probably document this behaviour, to avoid >> headaches :) > > The manpage says the serverID URL must use an FQDN. We already do a number > of > guesses in the code, I don't see any reason to extend this further. I'm sorry, but I was not referring to the serverID URI matching. I'm referring to syncrepl provider matching to listeners. I mentioned the serverID matching since it seems to work like syncrepl provider matching should. Regards, Jonathan

1 0

Re: (ITS#5941) Problem when stacking rwm and translucent overlays together
by ando＠sys-net.it 12 Feb '09

12 Feb '09

The problem can be easily reproduced, no need for further testing. However, I don't see an easy and clear fix right now. In the meanwhile, you should stack something in between to obtain the desired result. Having another proxy in between that deals with rwm could help. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5942) URI matching of "self" in add_syncrepl is incomplete
by hyc＠symas.com 12 Feb '09

12 Feb '09

Howard Chu wrote: > hyc(a)symas.com wrote: >> jclarke(a)linagora.com wrote: >>> I saw the comment in the code that clarifies this behaviour. However, it's a >>> surprising behaviour, and I think there is code to parse this kind of thing in >>> the serverID detection now. Maybe it could be reused? > > Oops, never mind. I was thinking of the serverID code, and you're talking > about the syncrepl code. > > I'll have to think a bit about why the two aren't behaving identically; > probably they should both use the same code. > Ah right. For the serverID code, we're doing a liberal match because anything that matches the current name:port is obviously the current server, and we want it to be identified as such. For syncrepl, we know full well that it may be the current server, but for whatever reason you may want to replicate against yourself anyway (e.g., against a different baseDN, etc...). -- -- 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#5942) URI matching of "self" in add_syncrepl is incomplete
by hyc＠symas.com 12 Feb '09

12 Feb '09

hyc(a)symas.com wrote: > jclarke(a)linagora.com wrote: >> Full_Name: Jonathan Clarke >> Version: RE24 >> OS: irrelevant >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (213.41.243.192) >> >> >> Hi, >> >> When adding a syncrepl config, the function add_syncrepl performs a "check if >> URL points to current server". This check is based on an exact match between the >> provider parameter from the syncrepl config line, and the URIs given to slapd on >> startup. >> >> If this doesn't match when it should, the database is marked as a shadow, and >> all following updates fail with "shadow context; no update refs". This is quite >> a pain when it happens on cn=config :) >> >> There are multiple cases when this happens: >> 1) If no specific URI was specified on launch (no -h option) >> 2) Port numbers are explicitly specified or not (":389") >> 3) Trailing slash (for example "ldap://1.2.3.4" != "ldap://1.2.3.4/") >> 4) IP is specified rather than DNS name ("ldap://localhost" != >> "ldap://127.0.0.1") >> >> I saw the comment in the code that clarifies this behaviour. However, it's a >> surprising behaviour, and I think there is code to parse this kind of thing in >> the serverID detection now. Maybe it could be reused? Oops, never mind. I was thinking of the serverID code, and you're talking about the syncrepl code. I'll have to think a bit about why the two aren't behaving identically; probably they should both use the same code. -- -- 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#5942) URI matching of "self" in add_syncrepl is incomplete
by hyc＠symas.com 12 Feb '09

12 Feb '09

jclarke(a)linagora.com wrote: > Full_Name: Jonathan Clarke > Version: RE24 > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (213.41.243.192) > > > Hi, > > When adding a syncrepl config, the function add_syncrepl performs a "check if > URL points to current server". This check is based on an exact match between the > provider parameter from the syncrepl config line, and the URIs given to slapd on > startup. > > If this doesn't match when it should, the database is marked as a shadow, and > all following updates fail with "shadow context; no update refs". This is quite > a pain when it happens on cn=config :) > > There are multiple cases when this happens: > 1) If no specific URI was specified on launch (no -h option) > 2) Port numbers are explicitly specified or not (":389") > 3) Trailing slash (for example "ldap://1.2.3.4" != "ldap://1.2.3.4/") > 4) IP is specified rather than DNS name ("ldap://localhost" != > "ldap://127.0.0.1") > > I saw the comment in the code that clarifies this behaviour. However, it's a > surprising behaviour, and I think there is code to parse this kind of thing in > the serverID detection now. Maybe it could be reused? > > Otherwise, we should probably document this behaviour, to avoid headaches :) The manpage says the serverID URL must use an FQDN. We already do a number of guesses in the code, I don't see any reason to extend this further. 1) with no URI the listener will default to localhost. The serverID URL should therefore refer to localhost, or omit the hostname. 2) Port numbers shouldn't be an issue, since they're always matched in the parsed URLs. 3) Trailing slashes don't matter in the parsed URLs. 4) The doc is quite explicit about using FQDN. I have no sympathy for people who trip over this. -- -- 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#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by philippe.eychart＠informatique.gov.pf 12 Feb '09

12 Feb '09

In fact, none of the LDAP clients need (can) write the directory servers. They (remote servers) only read informations needed to make (or upgrade) their own config files and to authenticate their own users. Client interfaces (web/php) allow the users to upgrade (or, according their profile, simply consult) the informations needed. Some of them (authorized "administrators" on remote sites) can to upgrade some more sensible informations (create/delete new users in their department, change them from groups, affect profile application softwares, create new emails/alias or proxy acces, upgrade departement informations or sometime, why not, administrate some new samba shares, ...) On central site, technicians of the hot-line or system administrators make the rest ... (of course, everything is not totally ended and work remains to be done ... What, as matter of fact, remains a good think concerning my remuneration ;-) --- PE -----Message d'origine----- De : Michael Ströder [mailto:michael@stroeder.com] Envoyé : jeudi 12 février 2009 00:29 À : Philippe EYCHART Cc : openldap-its(a)openldap.org Objet : Re: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine) Philippe EYCHART wrote: > philippe.eychart(a)informatique.gov.pf wrote: >> Used of SRV rr is a good reponse, (in particular in case of large Intranet >> with many >> remote sites -islands in pacific- and poor communication ressources - >> satellite) but require >> to be performed in all client applications : nssldap, samba, ldap client >> tools >> for rsync/mail/DNS/proxy/supervision definitions, ... or openldap. > > We are in this case : I work in Tahiti, for the french polynesian > gouvernment, IT departement. > Our intranet take in a big geographic area recovering several islands. > I'm in charge to transfer of the totality of our management systems (and > network config) in a centralized base (of course: openldap). > But, in one hand, distant servers (and users) can't be submit to > communication links quality, in particular concerning local services > (authentifications, local messaging, samba service, etc ...) and in other > hand, we can't multipy the number of ldap servers assuming redundence (quite > services merged, we already manage more than 100 servers - and about 4000 > pc). > So, one local server in every remote site must assume ldap service for the > other local servers (which assume different services for different > administrative departements) to guarantee acceptable performances (and also > to insure a certain insensitivity in break of communication links, at least > for local provided services) ; so, in case of an ldap server failure, the > redundance must be assumed by the central servers group, with the help of > SRV resolutions that (will) allow the ... excellent openldap library ;) > It seems to me that SRV RRs definition is actually a quite good answer (easy > to deploy and, why not, standardized) to this problematic. IMHO DNS RRs are not a good failover mechanism. The LDAP clients would have to be quite smart to do the right thing. Especially if LDAP clients are writing to the directory servers. Ciao, Michael.

1 0

(ITS#5942) URI matching of "self" in add_syncrepl is incomplete
by jclarke＠linagora.com 12 Feb '09

12 Feb '09

Full_Name: Jonathan Clarke Version: RE24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.41.243.192) Hi, When adding a syncrepl config, the function add_syncrepl performs a "check if URL points to current server". This check is based on an exact match between the provider parameter from the syncrepl config line, and the URIs given to slapd on startup. If this doesn't match when it should, the database is marked as a shadow, and all following updates fail with "shadow context; no update refs". This is quite a pain when it happens on cn=config :) There are multiple cases when this happens: 1) If no specific URI was specified on launch (no -h option) 2) Port numbers are explicitly specified or not (":389") 3) Trailing slash (for example "ldap://1.2.3.4" != "ldap://1.2.3.4/") 4) IP is specified rather than DNS name ("ldap://localhost" != "ldap://127.0.0.1") I saw the comment in the code that clarifies this behaviour. However, it's a surprising behaviour, and I think there is code to parse this kind of thing in the serverID detection now. Maybe it could be reused? Otherwise, we should probably document this behaviour, to avoid headaches :)

1 0

(ITS#5941) Problem when stacking rwm and translucent overlays together
by bryan.mesich＠ndsu.edu 12 Feb '09

12 Feb '09

Full_Name: Bryan Mesich Version: 2.4.13 OS: RHEL 5.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:4930:106:0:212:3fff:fefb:2891) When a rwm overlay is used in conjunction with the translucent overlay, slapd dies with the following error and backtrace: *** glibc detected *** ./libexec/slapd: double free or corruption (fasttop): 0x0860ca38 *** ======= Backtrace: ========= /lib/libc.so.6[0x5ceac1] /lib/libc.so.6(cfree+0x90)[0x5d20f0] ./libexec/slapd(do_search+0x10e)[0x807bbfe] ./libexec/slapd[0x8079845] ./libexec/slapd[0x8079c12] ./libexec/slapd[0x816d504] /lib/libpthread.so.0[0x6f750b] /lib/libc.so.6(clone+0x5e)[0x638b2e] I have been able to reproduce this error in 2.4.11, 2.4.13 and the CVS HEAD as of Mon Feb 9 11:13:04 CST 2009. Here is portion of my configuration file: ############################################### # database backend modules to load moduleload back_ldap.la # overlay modules to load moduleload translucent.la moduleload rwm.la # local database database bdb suffix "dc=nodak,dc=edu" rootdn "cn=root,dc=nodak,dc=edu" rootpw secret directory /var/lib/ldap2.4 overlay translucent uri "ldap://ldap.nodak.edu/"; overlay rwm #rwm-rewriteEngine on #rwm-rewriteContext searchFilter #rwm-rewriteRule "^(.*objectClass=)posixAccount(.*)" "$1inetOrgPerson$2" ":@" #rwm-map attribute uidNumber NID ############################################### Simply declaring the rwm overlay (as shown in my configuration) is enough to produce the error when used with a translucent overlay. Slapd will usually answer one request after being started before tipping over. I'm open to testing if needed. Thanks in advance, Bryan

1 0

RE: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by philippe.eychart＠informatique.gov.pf 11 Feb '09

11 Feb '09

philippe.eychart(a)informatique.gov.pf wrote: > Used of SRV rr is a good reponse, (in particular in case of large Intranet > with many > remote sites -islands in pacific- and poor communication ressources - > satellite) but require > to be performed in all client applications : nssldap, samba, ldap client > tools > for rsync/mail/DNS/proxy/supervision definitions, ... or openldap. We are in this case : I work in Tahiti, for the french polynesian gouvernment, IT departement. Our intranet take in a big geographic area recovering several islands. I'm in charge to transfer of the totality of our management systems (and network config) in a centralized base (of course: openldap). But, in one hand, distant servers (and users) can't be submit to communication links quality, in particular concerning local services (authentifications, local messaging, samba service, etc ...) and in other hand, we can't multipy the number of ldap servers assuming redundence (quite services merged, we already manage more than 100 servers - and about 4000 pc). So, one local server in every remote site must assume ldap service for the other local servers (which assume different services for different administrative departements) to guarantee acceptable performances (and also to insure a certain insensitivity in break of communication links, at least for local provided services) ; so, in case of an ldap server failure, the redundance must be assumed by the central servers group, with the help of SRV resolutions that (will) allow the ... excellent openldap library ;) It seems to me that SRV RRs definition is actually a quite good answer (easy to deploy and, why not, standardized) to this problematic. -----Message d'origine----- De : Michael Ströder [mailto:michael@stroeder.com] Envoyé : mercredi 11 février 2009 06:44 À : philippe.eychart(a)informatique.gov.pf Cc : openldap-its(a)openldap.org Objet : Re: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine) philippe.eychart(a)informatique.gov.pf wrote: > Michael Ströder wrote: >> Frankly I'd vote against stuffing this into standard function >> ldap_initialize(). Using this without further pre-caution (like >> user-interaction) is broken in a similar way like chasing LDAPv3 >> referrals at the client side. > > I also think myself that security aspects are important ; but in other hand, > IMHO : it is of the responsibility of the DNS administrator to configure > cleanly and to protect its systems of any corruption (and maybe also to the > project BIND to improve tools allowing it). DNSSEC would be a solution. But my question is which problem to solve at first with SRV RRs? Ciao, Michael.

1 0

Re: (ITS#5940) crash in slapo-rwm when modifying olcRwmRewrite
by ando＠sys-net.it 11 Feb '09

11 Feb '09

At a very quick glance of your backtrace, info == 0; you didn´t olcRwmRewiteEngine TRUE? If it´s the case, the code needs to be reworked in this area. I can´t look at this now, in the meanwhile try to set it to TRUE as your first slapo-rmw statement. p. ----- jclarke(a)linagora.com wrote: > Full_Name: Jonathan Clarke > Version: RE24 > OS: CentOS > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (213.41.243.192) > > > Hi, > > Given a simple setup involving back-ldap with slapo-rwm on top, modifying the > attribute "olcRwmRewrite" causes a crash. This seems to happen both while > modifying an existing value, or when deleting one. > > The config: > 8<---------------------------- > # {1}ldap, config > dn: olcDatabase={1}ldap,cn=config > objectClass: olcDatabaseConfig > objectClass: olcLDAPConfig > olcDatabase: {1}ldap > olcSuffix: o=proxy > olcAddContentAcl: FALSE > olcLastMod: FALSE > olcMaxDerefDepth: 15 > olcReadOnly: FALSE > olcMonitoring: FALSE > olcDbURI: "ldap://server.lan" > olcDbStartTLS: none > olcDbIDAssertBind: mode=none flags=prescriptive bindmethod=simple timeout=0 ne > twork-timeout=0 binddn="cn=administrateur,cn=users,dc=otherdemo,dc=lan" creden > tials="secret" > olcDbRebindAsUser: FALSE > olcDbChaseReferrals: TRUE > olcDbTFSupport: no > olcDbProxyWhoAmI: FALSE > olcDbSingleConn: FALSE > olcDbCancel: abandon > olcDbUseTemporaryConn: FALSE > olcDbConnectionPoolMax: 16 > olcDbNoRefs: FALSE > olcDbNoUndefFilter: FALSE > > # {0}rwm, {1}ldap, config > dn: olcOverlay={0}rwm,olcDatabase={1}ldap,cn=config > objectClass: olcOverlayConfig > objectClass: olcRwmConfig > olcOverlay: {0}rwm > olcRwmRewrite: {0}rwm-suffixmassage "o=proxy" "dc=otherdemo,dc=lan" > olcRwmTFSupport: false > olcRwmNormalizeMapped: FALSE > 8<---------------------------- > > The operation: > 8<---------------------------- > dn: olcOverlay={0}rwm,olcDatabase={1}ldap,cn=config > changeType: modify > replace: olcRwmRewrite > olcRwmRewrite: {0}rwm-suffixmassage "o=proxy" "dc=demo,dc=lan" > > 8<---------------------------- > > > GDB output: > 8<---------------------------- > conn=4 fd=12 ACCEPT from IP=127.0.0.1:45843 (IP=0.0.0.0:389) > conn=4 op=0 BIND dn="cn=config" method=128 > conn=4 op=0 BIND dn="cn=config" mech=SIMPLE ssf=0 > conn=4 op=0 RESULT tag=97 err=0 text= > conn=4 op=1 MOD dn="olcOverlay={0}rwm,olcDatabase={1}ldap,cn=config" > conn=4 op=1 MOD attr=olcRwmRewrite > slapd: config.c:59: rewrite_parse: Assertion `info != ((void *)0)' failed. > > Program received signal SIGABRT, Aborted. > [Switching to Thread 1106893120 (LWP 31852)] > 0x0000003411a30155 in raise () from /lib64/libc.so.6 > (gdb) bt > #0 0x0000003411a30155 in raise () from /lib64/libc.so.6 > #1 0x0000003411a31bf0 in abort () from /lib64/libc.so.6 > #2 0x0000003411a295d6 in __assert_fail () from /lib64/libc.so.6 > #3 0x00000000004ea899 in rewrite_parse (info=0x0, fname=0x555ec5 "<suffix > massage>", lineno=1, argc=2, argv=0x41f9a180) at config.c:59 > #4 0x00000000004df8fe in rwm_suffix_massage_config (info=0x7c6a, > pvnc=0x41f9a220, nvnc=<value optimized out>, prnc=0x41f9a1f0, nrnc=<value > optimized out>) > at rwmconf.c:326 > #5 0x00000000004dc1bd in rwm_suffixmassage_config (be=<value optimized out>, > fname=0x523789 "slapd", lineno=0, argc=<value optimized out>, > argv=<value optimized out>) at rwm.c:1662 > #6 0x00000000004dc632 in rwm_cf_gen (c=0x41f9a620) at rwm.c:2076 > #7 0x0000000000414b7b in config_set_vals (Conf=0x7abc00, c=0x7c6c) at > config.c:314 > #8 0x000000000041835d in config_parse_add (ct=0x7abc00, c=0x41f9a620, > valx=<value optimized out>) at config.c:642 > #9 0x000000000040e63f in config_modify_add (ct=0x7abc00, ca=0x41f9a620, > ad=<value optimized out>, i=0) at bconfig.c:4806 > #10 0x0000000000410b03 in config_back_modify (op=0x1c8bf360, rs=0x41f9cc20) at > bconfig.c:5039 > #11 0x0000000000434317 in fe_op_modify (op=0x1c8bf360, rs=0x41f9cc20) at > modify.c:301 > #12 0x0000000000434a72 in do_modify (op=0x1c8bf360, rs=0x41f9cc20) at > modify.c:175 > #13 0x000000000041dd2b in connection_operation (ctx=0x41f9cd70, arg_v=<value > optimized out>) at connection.c:1097 > #14 0x000000000041e207 in connection_read_thread (ctx=0x41f9cd70, argv=<value > optimized out>) at connection.c:1223 > #15 0x00000000004f906a in ldap_int_thread_pool_wrapper (xpool=0x1c83c2d0) at > tpool.c:663 > #16 0x00002b6a8d3532f7 in start_thread () from /lib64/libpthread.so.0 > #17 0x0000003411ad1e3d in clone () from /lib64/libc.so.6 > 8<---------------------------- > > Let me know if you need any more details, or output from GDB. > > Regards, > Jonathan > > 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5940) crash in slapo-rwm when modifying olcRwmRewrite
by jclarke＠linagora.com 11 Feb '09

11 Feb '09

Full_Name: Jonathan Clarke Version: RE24 OS: CentOS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.41.243.192) Hi, Given a simple setup involving back-ldap with slapo-rwm on top, modifying the attribute "olcRwmRewrite" causes a crash. This seems to happen both while modifying an existing value, or when deleting one. The config: 8<---------------------------- # {1}ldap, config dn: olcDatabase={1}ldap,cn=config objectClass: olcDatabaseConfig objectClass: olcLDAPConfig olcDatabase: {1}ldap olcSuffix: o=proxy olcAddContentAcl: FALSE olcLastMod: FALSE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcMonitoring: FALSE olcDbURI: "ldap://server.lan" olcDbStartTLS: none olcDbIDAssertBind: mode=none flags=prescriptive bindmethod=simple timeout=0 ne twork-timeout=0 binddn="cn=administrateur,cn=users,dc=otherdemo,dc=lan" creden tials="secret" olcDbRebindAsUser: FALSE olcDbChaseReferrals: TRUE olcDbTFSupport: no olcDbProxyWhoAmI: FALSE olcDbSingleConn: FALSE olcDbCancel: abandon olcDbUseTemporaryConn: FALSE olcDbConnectionPoolMax: 16 olcDbNoRefs: FALSE olcDbNoUndefFilter: FALSE # {0}rwm, {1}ldap, config dn: olcOverlay={0}rwm,olcDatabase={1}ldap,cn=config objectClass: olcOverlayConfig objectClass: olcRwmConfig olcOverlay: {0}rwm olcRwmRewrite: {0}rwm-suffixmassage "o=proxy" "dc=otherdemo,dc=lan" olcRwmTFSupport: false olcRwmNormalizeMapped: FALSE 8<---------------------------- The operation: 8<---------------------------- dn: olcOverlay={0}rwm,olcDatabase={1}ldap,cn=config changeType: modify replace: olcRwmRewrite olcRwmRewrite: {0}rwm-suffixmassage "o=proxy" "dc=demo,dc=lan" 8<---------------------------- GDB output: 8<---------------------------- conn=4 fd=12 ACCEPT from IP=127.0.0.1:45843 (IP=0.0.0.0:389) conn=4 op=0 BIND dn="cn=config" method=128 conn=4 op=0 BIND dn="cn=config" mech=SIMPLE ssf=0 conn=4 op=0 RESULT tag=97 err=0 text= conn=4 op=1 MOD dn="olcOverlay={0}rwm,olcDatabase={1}ldap,cn=config" conn=4 op=1 MOD attr=olcRwmRewrite slapd: config.c:59: rewrite_parse: Assertion `info != ((void *)0)' failed. Program received signal SIGABRT, Aborted. [Switching to Thread 1106893120 (LWP 31852)] 0x0000003411a30155 in raise () from /lib64/libc.so.6 (gdb) bt #0 0x0000003411a30155 in raise () from /lib64/libc.so.6 #1 0x0000003411a31bf0 in abort () from /lib64/libc.so.6 #2 0x0000003411a295d6 in __assert_fail () from /lib64/libc.so.6 #3 0x00000000004ea899 in rewrite_parse (info=0x0, fname=0x555ec5 "<suffix massage>", lineno=1, argc=2, argv=0x41f9a180) at config.c:59 #4 0x00000000004df8fe in rwm_suffix_massage_config (info=0x7c6a, pvnc=0x41f9a220, nvnc=<value optimized out>, prnc=0x41f9a1f0, nrnc=<value optimized out>) at rwmconf.c:326 #5 0x00000000004dc1bd in rwm_suffixmassage_config (be=<value optimized out>, fname=0x523789 "slapd", lineno=0, argc=<value optimized out>, argv=<value optimized out>) at rwm.c:1662 #6 0x00000000004dc632 in rwm_cf_gen (c=0x41f9a620) at rwm.c:2076 #7 0x0000000000414b7b in config_set_vals (Conf=0x7abc00, c=0x7c6c) at config.c:314 #8 0x000000000041835d in config_parse_add (ct=0x7abc00, c=0x41f9a620, valx=<value optimized out>) at config.c:642 #9 0x000000000040e63f in config_modify_add (ct=0x7abc00, ca=0x41f9a620, ad=<value optimized out>, i=0) at bconfig.c:4806 #10 0x0000000000410b03 in config_back_modify (op=0x1c8bf360, rs=0x41f9cc20) at bconfig.c:5039 #11 0x0000000000434317 in fe_op_modify (op=0x1c8bf360, rs=0x41f9cc20) at modify.c:301 #12 0x0000000000434a72 in do_modify (op=0x1c8bf360, rs=0x41f9cc20) at modify.c:175 #13 0x000000000041dd2b in connection_operation (ctx=0x41f9cd70, arg_v=<value optimized out>) at connection.c:1097 #14 0x000000000041e207 in connection_read_thread (ctx=0x41f9cd70, argv=<value optimized out>) at connection.c:1223 #15 0x00000000004f906a in ldap_int_thread_pool_wrapper (xpool=0x1c83c2d0) at tpool.c:663 #16 0x00002b6a8d3532f7 in start_thread () from /lib64/libpthread.so.0 #17 0x0000003411ad1e3d in clone () from /lib64/libc.so.6 8<---------------------------- Let me know if you need any more details, or output from GDB. Regards, Jonathan

1 0

Re: (ITS#5756) 2.4 slapo-pcache only caches first lookup for certain templates
by toby＠inf.ed.ac.uk 11 Feb '09

11 Feb '09

Brilliant, many thanks for this. A simple test seems to confirm that it fixes the problem. I'll test in more detail and with more complex filters to confirm. Cheers Toby -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

Re: (ITS#5938) tls.c does not conform to RFC 4513
by hyc＠symas.com 10 Feb '09

10 Feb '09

nick.hudson(a)isode.com wrote: > Full_Name: nick hudson > Version: 2.3.38 > OS: linux > URL: > Submission from: (NULL) (62.3.217.250) > > > I am looking at the code in tls.c, function ldap_pvt_tls_check_hostname > (although the code has been refactored in recent versions, into e.g. tls_o.c, > but the same is true of the new code) > > I think the code is doing something that RFC 4513 says that it should not do. > Specifically, ref RFC 4513 section 3.1.3 says: > > The server's identity may also be verified by comparing the reference > identity to the Common Name (CN) [RFC4519] value in the leaf Relative > Distinguished Name (RDN) of the subjectName field of the server's > certificate. This comparison is performed using the rules for > comparison of DNS names in Section 3.1.3.1, below, with the exception > that no wildcard matching is allowed. > > In tls.c (and the refactored code), you can see it's first attempting an exact > comparison on subjectAltName, and if that fails it tries a wildcard match (which > is ok, as per section 3.1.3.1) > > But if no subjectAltName match is found, there's another section which looks at > the certificate's subjectname, in which it also does a wildcard match, although > the RFC says this shouldn't be done. I recall having a long argument against adding this, but we went with it in the end. The original patch was in ITS#3134. Some of the discussion surfaced here http://www.openldap.org/lists/openldap-software/200404/msg00434.html It carried on here http://www.openldap.org/lists/openldap-devel/200405/msg00002.html I'll also note ITS#5789, we allow matching an IP address against the CN too, and according to the spec that's only allowed for subjectAltName. But obviously there are lots of people out there misusing X.509, and we're tired of telling them to go do it right. It's a losing battle, we just get blamed for being broken... -- -- 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#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by philippe.eychart＠informatique.gov.pf 10 Feb '09

10 Feb '09

Pierangelo Masarati [mailto:ando@sys-net.it] wrote: > OpenLDAP clients do the following: > empty hostport, empty DN: localhost, default port > empty hostport, non-empty DN: SRV > what might be missing IMHO is: > use domain to specify SRV > however, I don't see any special need for it, as domain can always be > put in DN form. > I don't know if there's need for a form that asks to use SRV to discover > the server for the default SUFFIX. > In order to avoid issues, I recommend using something like > x-dnssrv={<domain>|<DN>} > where <DN> is restricted to the domain component sequence form. Ok, I start on this agreement ... So, is it a Good Thing (IYHO ;) to introduce this patch according the "followup 9" ?... One other possible solution could be (for example) to patch the ldap_connect_to_host() function in os-ip.c (around getaddrinfo() and ldap_pvt_gethostbyname_a() calls). However, samba (as an example) seems not to use it ... I think that the first solution remains the one who will have a minimal impact on the existing sources ... Michael Str.der wrote: > Frankly I'd vote against stuffing this into standard function > ldap_initialize(). Using this without further pre-caution (like > user-interaction) is broken in a similar way like chasing LDAPv3 > referrals at the client side. I also think myself that security aspects are important ; but in other hand, IMHO : it is of the responsibility of the DNS administrator to configure cleanly and to protect its systems of any corruption (and maybe also to the project BIND to improve tools allowing it). Although it is there, the advantage of the suggested solution ("followup 9") is as well as this patch can be located as well within the function ldap_initialize() as within another frontal function (according to what will be finally decided ;). --- PE

1 0

Re: (ITS#5931) back-meta crashes with syncrepl data
by ando＠sys-net.it 10 Feb '09

10 Feb '09

> Right, I did the same first with test017. I've now repeated with > test018, > which works fine since the intermediate message carries the sync > cookie. Ah, I never checked refreshOnly, as it's not an option I use often. Well, the issue about response controls needs to be solved at some point. In any case, proxying syncrepl this way should not be regular usage. I'm happy it helped sorting out some issues in the proxies. Fine for the liblber patch to be backed out, then. I can't test right now, but I don't see any reason to have a different behavior than yours. What puzzles me now is that I had to rework entry parsing in back-meta to prevent it eating entry controls while parsing attributes, but back-ldap didn't need anything like that... 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5931) back-meta crashes with syncrepl data
by hyc＠symas.com 10 Feb '09

10 Feb '09

Pierangelo Masarati wrote: > ----- hyc(a)symas.com ha scritto: > >> hyc(a)symas.com wrote: >>> I'll play with this code some with the decode change backed out. >>> >> Heh, in my current build I hadn't updated liblber yet so I didn't have >> the >> change. Fwiw, test036 etc. worked fine without it. Will try some >> syncrepl >> configs now. > > I ran test018, then I put a back-meta between the consumer and the > producer, I wiped the consumer's database and restarted it. Then I performed some further modifications to the producer and checked that they appeared in the consumer. Right, I did the same first with test017. I've now repeated with test018, which works fine since the intermediate message carries the sync cookie. > Please pay attention to the proxy's logs: what you could (should) get is a series of messages complaining about the impossibility to decode attribute types. I didn't see any such errors in the proxy's logs, and the consumer was fine. > I might well have screwed something up while trying to fix intermediate responses and other stuff related to this ITS. That's why I'm asking for critical review before merging my fix into re24. With the change in liblber I could perform syncrepl with back-meta in between. refreshAndPersist seems to work fine without the liblber patch. -- -- 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#5931) back-meta crashes with syncrepl data
by hyc＠symas.com 10 Feb '09

10 Feb '09

hyc(a)symas.com wrote: > hyc(a)symas.com wrote: >> I'll play with this code some with the decode change backed out. >> > Heh, in my current build I hadn't updated liblber yet so I didn't have the > change. Fwiw, test036 etc. worked fine without it. Will try some syncrepl > configs now. > back-meta passes search entry controls fine without the liblber patch. But since back-meta doesn't pass result controls, (ITS#4591) it never propagates the final cookie in refreshonly mode, so the consumer always gets a full refresh every time it reconnects. I'm going to revert the liblber patch. -- -- 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#5931) back-meta crashes with syncrepl data
by ando＠sys-net.it 10 Feb '09

10 Feb '09

----- hyc(a)symas.com ha scritto: > hyc(a)symas.com wrote: > > I'll play with this code some with the decode change backed out. > > > Heh, in my current build I hadn't updated liblber yet so I didn't have > the > change. Fwiw, test036 etc. worked fine without it. Will try some > syncrepl > configs now. I ran test018, then I put a back-meta between the consumer and the producer, I wiped the consumer's database and restarted it. Then I performed some further modifications to the producer and checked that they appeared in the consumer. Please pay attention to the proxy's logs: what you could (should) get is a series of messages complaining about the impossibility to decode attribute types. I might well have screwed something up while trying to fix intermediate responses and other stuff related to this ITS. That's why I'm asking for critical review before merging my fix into re24. With the change in liblber I could perform syncrepl with back-meta in between. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5931) back-meta crashes with syncrepl data
by hyc＠symas.com 10 Feb '09

10 Feb '09

hyc(a)symas.com wrote: > I'll play with this code some with the decode change backed out. > Heh, in my current build I hadn't updated liblber yet so I didn't have the change. Fwiw, test036 etc. worked fine without it. Will try some syncrepl configs now. -- -- 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#5931) back-meta crashes with syncrepl data
by hyc＠symas.com 10 Feb '09

10 Feb '09

Pierangelo Masarati wrote: > ----- "Howard Chu"<hyc(a)symas.com> ha scritto: > >> ando(a)sys-net.it wrote: >>> I'm trying to modify the code in order to compute the size of the >>> SearchResultEntry portion of the message, but again, in some cases, >> the >>> size is computed incorrectly: the computed length is 4 octets >> shorter >>> than what's actually in the packet. >>> >>> One issue seems to be related to the fact that when ber_skip_tag() >>> checks if the length it's computed fits in the ber by calling >>> ber_pvt_ber_remaining(), it doesn't count that earlier calls to >>> ber_read() moved the ber_ptr forward. The original ber_ptr should >> be saved. >> >> This sounds wrong; the bytes that ber_read() advanced comprise the >> length >> bytes, but they're not included in the total that the length is >> counting. >> Therefore they should not be accounted for here. > > But without this fix ber_scanf("l") LBER_ERROR was failing because > ber_pvt_ber_remaining(), which is actually ber_end - ber_ptr, is shorter > than *len by the bytes that the ber_reads are advancing. Feel free to back > this out, if you're sure it's incorrect. I'll recheck the syncrepl over > back-meta. Pretty sure. Notice ber_first_element: *last = ber->ber_ptr + *len; All of this has been working for quite a long time... I'll play with this code some with the decode change backed out. -- -- 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#5931) back-meta crashes with syncrepl data
by ando＠sys-net.it 10 Feb '09

10 Feb '09

----- "Howard Chu" <hyc(a)symas.com> ha scritto: > ando(a)sys-net.it wrote: > > I'm trying to modify the code in order to compute the size of the > > SearchResultEntry portion of the message, but again, in some cases, > the > > size is computed incorrectly: the computed length is 4 octets > shorter > > than what's actually in the packet. > > > > One issue seems to be related to the fact that when ber_skip_tag() > > checks if the length it's computed fits in the ber by calling > > ber_pvt_ber_remaining(), it doesn't count that earlier calls to > > ber_read() moved the ber_ptr forward. The original ber_ptr should > be saved. > > This sounds wrong; the bytes that ber_read() advanced comprise the > length > bytes, but they're not included in the total that the length is > counting. > Therefore they should not be accounted for here. But without this fix ber_scanf("l") LBER_ERROR was failing because ber_pvt_ber_remaining(), which is actually ber_end - ber_ptr, is shorter than *len by the bytes that the ber_reads are advancing. Feel free to back this out, if you're sure it's incorrect. I'll recheck the syncrepl over back-meta. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5931) back-meta crashes with syncrepl data
by hyc＠symas.com 10 Feb '09

10 Feb '09

ando(a)sys-net.it wrote: > I'm trying to modify the code in order to compute the size of the > SearchResultEntry portion of the message, but again, in some cases, the > size is computed incorrectly: the computed length is 4 octets shorter > than what's actually in the packet. > > One issue seems to be related to the fact that when ber_skip_tag() > checks if the length it's computed fits in the ber by calling > ber_pvt_ber_remaining(), it doesn't count that earlier calls to > ber_read() moved the ber_ptr forward. The original ber_ptr should be saved. This sounds wrong; the bytes that ber_read() advanced comprise the length bytes, but they're not included in the total that the length is counting. Therefore they should not be accounted for here. > I don't believe messages are encoded incorrectly, so I must be doing > something wrong in decoding them... -- -- 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#5939) Missing close of file descriptor
by hyc＠symas.com 10 Feb '09

10 Feb '09

joakim.bentholm(a)birdstep.com wrote: > Full_Name: Joakim Bentholm > Version: OpenLDAP 2.4.13 > OS: FreeBSD 7.0 Release > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (217.13.255.38) > > > The running setup: > An ldap server with a socket back-end communicating with server process > listening on incoming requests from the socket back-end and replying in an > orderly fashing. > > The failure: > If the server process shuts down, the socket back-end will continue to try to > connect and allocating new file descriptors which will never be released. If the > server process is restarted everything will work, unless the file descriptor > limit have been reached, in case the ldap server have to be restart. Thanks for the report and patch, fixed now in HEAD. -- -- 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#5938) tls.c does not conform to RFC 4513
by quanah＠zimbra.com 10 Feb '09

10 Feb '09

--On February 10, 2009 5:28:24 PM +0100 Hallvard B Furuseth <h.b.furuseth(a)usit.uio.no> wrote: > quanah(a)zimbra.com writes: >> This is because the Cert vendors themselves don't honor the RFC's when >> issuing wildcard certs, and was added so that their broken wildcard >> certs could still be used. > > In that case, maybe there should be a config option to turn this > behavior on/off, and documentation which explains that it breaks TLS > the standard and why it does so. > > If nothing else, it may get more people to complain to the cert vendors. I spent something like 4 hours on the phone discussing the issue with one of the cert vendors. They still didn't understand what was wrong with their cert, and to this day they still issue the same style of certs. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5938) tls.c does not conform to RFC 4513
by Kurt＠OpenLDAP.org 10 Feb '09

10 Feb '09

On Feb 10, 2009, at 8:29 AM, h.b.furuseth(a)usit.uio.no wrote: > quanah(a)zimbra.com writes: >> This is because the Cert vendors themselves don't honor the RFC's >> when >> issuing wildcard certs, and was added so that their broken wildcard >> certs could still be used. > > In that case, maybe there should be a config option to turn this > behavior on/off, and documentation which explains that it breaks TLS > the standard and why it does so. I think it reasonable to be liberal in what we accept in this particular case. It's not like someone is actually going to name a host '*'. If they do, their certificate matching more hosts than they expect will be just one of many problems they face. > > > If nothing else, it may get more people to complain to the cert > vendors. Far more persons would complain to the OpenLDAP Project.

1 0

Re: (ITS#5938) tls.c does not conform to RFC 4513
by h.b.furuseth＠usit.uio.no 10 Feb '09

10 Feb '09

quanah(a)zimbra.com writes: > This is because the Cert vendors themselves don't honor the RFC's when > issuing wildcard certs, and was added so that their broken wildcard > certs could still be used. In that case, maybe there should be a config option to turn this behavior on/off, and documentation which explains that it breaks TLS the standard and why it does so. If nothing else, it may get more people to complain to the cert vendors. -- Hallvard

1 0

Re: (ITS#5938) tls.c does not conform to RFC 4513
by Kurt＠OpenLDAP.org 10 Feb '09

10 Feb '09

On Feb 10, 2009, at 7:56 AM, nick.hudson(a)isode.com wrote: > Full_Name: nick hudson > Version: 2.3.38 > OS: linux > URL: > Submission from: (NULL) (62.3.217.250) > > > I am looking at the code in tls.c, function > ldap_pvt_tls_check_hostname > (although the code has been refactored in recent versions, into e.g. > tls_o.c, > but the same is true of the new code) > > I think the code is doing something that RFC 4513 says that it > should not do. > Specifically, ref RFC 4513 section 3.1.3 says: > > The server's identity may also be verified by comparing the > reference > identity to the Common Name (CN) [RFC4519] value in the leaf > Relative > Distinguished Name (RDN) of the subjectName field of the server's > certificate. This comparison is performed using the rules for > comparison of DNS names in Section 3.1.3.1, below, with the > exception > that no wildcard matching is allowed. > > In tls.c (and the refactored code), you can see it's first > attempting an exact > comparison on subjectAltName, and if that fails it tries a wildcard > match (which > is ok, as per section 3.1.3.1) > > But if no subjectAltName match is found, there's another section > which looks at > the certificate's subjectname, in which it also does a wildcard > match, although > the RFC says this shouldn't be done. This is a case where OpenLDAP library is purposely being 'liberal in what it accepts'. -- Kurt

1 0

Re: (ITS#5938) tls.c does not conform to RFC 4513
by quanah＠zimbra.com 10 Feb '09

10 Feb '09

--On February 10, 2009 3:56:37 PM +0000 nick.hudson(a)isode.com wrote: > Full_Name: nick hudson > Version: 2.3.38 > OS: linux > URL: > Submission from: (NULL) (62.3.217.250) > > > I am looking at the code in tls.c, function ldap_pvt_tls_check_hostname > (although the code has been refactored in recent versions, into e.g. > tls_o.c, but the same is true of the new code) > > I think the code is doing something that RFC 4513 says that it should not > do. Specifically, ref RFC 4513 section 3.1.3 says: > > The server's identity may also be verified by comparing the reference > identity to the Common Name (CN) [RFC4519] value in the leaf Relative > Distinguished Name (RDN) of the subjectName field of the server's > certificate. This comparison is performed using the rules for > comparison of DNS names in Section 3.1.3.1, below, with the exception > that no wildcard matching is allowed. > > In tls.c (and the refactored code), you can see it's first attempting an > exact comparison on subjectAltName, and if that fails it tries a wildcard > match (which is ok, as per section 3.1.3.1) > > But if no subjectAltName match is found, there's another section which > looks at the certificate's subjectname, in which it also does a wildcard > match, although the RFC says this shouldn't be done. This is because the Cert vendors themselves don't honor the RFC's when issuing wildcard certs, and was added so that their broken wildcard certs could still be used. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5939) Missing close of file descriptor
by joakim.bentholm＠birdstep.com 10 Feb '09

10 Feb '09

Full_Name: Joakim Bentholm Version: OpenLDAP 2.4.13 OS: FreeBSD 7.0 Release URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.13.255.38) The running setup: An ldap server with a socket back-end communicating with server process listening on incoming requests from the socket back-end and replying in an orderly fashing. The failure: If the server process shuts down, the socket back-end will continue to try to connect and allocating new file descriptors which will never be released. If the server process is restarted everything will work, unless the file descriptor limit have been reached, in case the ldap server have to be restart. Solution: close the file descripton The following patch solves the problem --- --- servers/slapd/back-sock/opensock.c.orig 2008-02-09 01:46:09.000000000 +0100 +++ servers/slapd/back-sock/opensock.c 2009-02-02 16:09:24.000000000 +0100 @@ -57,6 +57,7 @@ if ( connect( fd, (struct sockaddr *)&sockun, sizeof(sockun) ) < 0 ) { Debug( LDAP_DEBUG_ANY, "socket connect(%s) failed\n", sockpath ? sockpath : "<null>", 0, 0 ); + close( fd ); return( NULL ); } ---

1 0

(ITS#5938) tls.c does not conform to RFC 4513
by nick.hudson＠isode.com 10 Feb '09

10 Feb '09

Full_Name: nick hudson Version: 2.3.38 OS: linux URL: Submission from: (NULL) (62.3.217.250) I am looking at the code in tls.c, function ldap_pvt_tls_check_hostname (although the code has been refactored in recent versions, into e.g. tls_o.c, but the same is true of the new code) I think the code is doing something that RFC 4513 says that it should not do. Specifically, ref RFC 4513 section 3.1.3 says: The server's identity may also be verified by comparing the reference identity to the Common Name (CN) [RFC4519] value in the leaf Relative Distinguished Name (RDN) of the subjectName field of the server's certificate. This comparison is performed using the rules for comparison of DNS names in Section 3.1.3.1, below, with the exception that no wildcard matching is allowed. In tls.c (and the refactored code), you can see it's first attempting an exact comparison on subjectAltName, and if that fails it tries a wildcard match (which is ok, as per section 3.1.3.1) But if no subjectAltName match is found, there's another section which looks at the certificate's subjectname, in which it also does a wildcard match, although the RFC says this shouldn't be done.

1 0

Re: (ITS#5937) Apparent mistake in ipv6 address handling in tls.c
by hyc＠symas.com 10 Feb '09

10 Feb '09

Kurt Zeilenga wrote: > On Feb 10, 2009, at 4:27 AM, hyc(a)symas.com wrote: >> Nice catch, that's been in there since 2002. Fixed in HEAD. > > I counted 5 occurs in HEAD tls*.c... 2 of those are in tls.c, which is no longer being compiled. I just haven't got around to cvs rm'ing it yet after splitting to tls2.c and the other modules. -- -- 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#5937) Apparent mistake in ipv6 address handling in tls.c
by Kurt＠OpenLDAP.org 10 Feb '09

10 Feb '09

On Feb 10, 2009, at 4:27 AM, hyc(a)symas.com wrote: > nick.hudson(a)isode.com wrote: >> Full_Name: nick hudson >> Version: 2.3.38 >> OS: linux >> URL: >> Submission from: (NULL) (62.3.217.250) >> >> >> I think there is a bug in libraries/libldap/tls.c - specifically in >> this >> section: >> >> #ifdef LDAP_PF_INET6 >> if (name[0] == '['&& strchr(name, ']')) { >> char *n2 = ldap_strdup(name+1); >> *strchr(n2, ']') = 2; >> if (inet_pton(AF_INET6, n2,&addr)) >> ntype = IS_IP6; >> LDAP_FREE(n2); >> } else >> #endif >> >> the code is attempting to detect whether part of an LDAP URL >> represents an IPv6 >> address; it passes the string to inet_pton(), after removing square >> brackets. >> But I think this line: >> >> *strchr(n2, ']') = 2; >> >> is wrong: shouldn't it be using 0 instead of 2? >> >> When testing on my local system, using the code above always >> results in >> inet_pton returning 0 (not an IPv6 address) - if I modify the >> strchr line to use >> zero instead, then inet_pton returns 1 for valid IPv6 addresses. >> >> I may be missing something - "2" seems a peculiar value to use so >> perhaps it >> does have some special significance - but I think the code as it >> stands is >> incorrect. > > Nice catch, that's been in there since 2002. Fixed in HEAD. I counted 5 occurs in HEAD tls*.c... -- Kurt

1 0

Re: (ITS#5936) test049 uses nonexistant variable SLEEP1
by hyc＠symas.com 10 Feb '09

10 Feb '09

jclarke(a)linagora.com wrote: > Full_Name: Jonathan Clarke > Version: RE24 > OS: irrelevant > URL: http://milopita.phillipoux.net/jonathan-clarke-20090210-test049.patch > Submission from: (NULL) (213.41.243.192) > > > test049 complains with: > Waiting seconds for syncrepl to receive changes... > sleep: missing operator > > The patch below corrects this. Using 10 seconds as default value, as is done > above in the test script for cn=config replication. > > > Thanks, fixed. I guess we probably should just sync up the rest of the test scripts between HEAD and RE24 after all, since we've tripped over this a few times already. -- -- 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#5937) Apparent mistake in ipv6 address handling in tls.c
by hyc＠symas.com 10 Feb '09

10 Feb '09

nick.hudson(a)isode.com wrote: > Full_Name: nick hudson > Version: 2.3.38 > OS: linux > URL: > Submission from: (NULL) (62.3.217.250) > > > I think there is a bug in libraries/libldap/tls.c - specifically in this > section: > > #ifdef LDAP_PF_INET6 > if (name[0] == '['&& strchr(name, ']')) { > char *n2 = ldap_strdup(name+1); > *strchr(n2, ']') = 2; > if (inet_pton(AF_INET6, n2,&addr)) > ntype = IS_IP6; > LDAP_FREE(n2); > } else > #endif > > the code is attempting to detect whether part of an LDAP URL represents an IPv6 > address; it passes the string to inet_pton(), after removing square brackets. > But I think this line: > > *strchr(n2, ']') = 2; > > is wrong: shouldn't it be using 0 instead of 2? > > When testing on my local system, using the code above always results in > inet_pton returning 0 (not an IPv6 address) - if I modify the strchr line to use > zero instead, then inet_pton returns 1 for valid IPv6 addresses. > > I may be missing something - "2" seems a peculiar value to use so perhaps it > does have some special significance - but I think the code as it stands is > incorrect. Nice catch, that's been in there since 2002. Fixed in HEAD. -- -- 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#5937) Apparent mistake in ipv6 address handling in tls.c
by nick.hudson＠isode.com 10 Feb '09

10 Feb '09

Full_Name: nick hudson Version: 2.3.38 OS: linux URL: Submission from: (NULL) (62.3.217.250) I think there is a bug in libraries/libldap/tls.c - specifically in this section: #ifdef LDAP_PF_INET6 if (name[0] == '[' && strchr(name, ']')) { char *n2 = ldap_strdup(name+1); *strchr(n2, ']') = 2; if (inet_pton(AF_INET6, n2, &addr)) ntype = IS_IP6; LDAP_FREE(n2); } else #endif the code is attempting to detect whether part of an LDAP URL represents an IPv6 address; it passes the string to inet_pton(), after removing square brackets. But I think this line: *strchr(n2, ']') = 2; is wrong: shouldn't it be using 0 instead of 2? When testing on my local system, using the code above always results in inet_pton returning 0 (not an IPv6 address) - if I modify the strchr line to use zero instead, then inet_pton returns 1 for valid IPv6 addresses. I may be missing something - "2" seems a peculiar value to use so perhaps it does have some special significance - but I think the code as it stands is incorrect.

1 0

(ITS#5936) test049 uses nonexistant variable SLEEP1
by jclarke＠linagora.com 10 Feb '09

10 Feb '09

Full_Name: Jonathan Clarke Version: RE24 OS: irrelevant URL: http://milopita.phillipoux.net/jonathan-clarke-20090210-test049.patch Submission from: (NULL) (213.41.243.192) test049 complains with: Waiting seconds for syncrepl to receive changes... sleep: missing operator The patch below corrects this. Using 10 seconds as default value, as is done above in the test script for cn=config replication.

1 0

Re: (ITS#5929) 'make test' uses installed libldap_r/liblber
by hyc＠symas.com 10 Feb '09

10 Feb '09

h.b.furuseth(a)usit.uio.no wrote: > Thanks for checking this out. > >> If you want this to work you'll have to provide both the build >> directory and your installed directory in your -rpath. > > Doesn't sound good either. Then I presume the installed binaries may > later use libraries from a test build. Probably. You can of course edit the relink commands in the wrapper to eliminate the build runpath, but it's a lot of manual intervention no matter how you slice it. > >> The symlinks would then help a little, because you only need to set >> one build rpath instead of 3. Go ahead and restore the build rules in >> your source tree to set the symlinks if you want them. At the moment >> it looks like they're not generally useful, and I'm tired of >> committing/reverting, so I'm not touching those files any more today. > > I don't have time for this now either, but I'll hopefully get to it > soon. I wonder if a fix will be to revert the recent libtool upgrade:-( > > Of course it may be that this situation has existed for ages but I only > noticed because of the missing ldap_pvt_search symbol. > The build rules were changed in OL 2.1, it's been like this for ages... -- -- 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#5929) 'make test' uses installed libldap_r/liblber
by h.b.furuseth＠usit.uio.no 10 Feb '09

10 Feb '09

Thanks for checking this out. > If you want this to work you'll have to provide both the build > directory and your installed directory in your -rpath. Doesn't sound good either. Then I presume the installed binaries may later use libraries from a test build. > The symlinks would then help a little, because you only need to set > one build rpath instead of 3. Go ahead and restore the build rules in > your source tree to set the symlinks if you want them. At the moment > it looks like they're not generally useful, and I'm tired of > committing/reverting, so I'm not touching those files any more today. I don't have time for this now either, but I'll hopefully get to it soon. I wonder if a fix will be to revert the recent libtool upgrade:-( Of course it may be that this situation has existed for ages but I only noticed because of the missing ldap_pvt_search symbol. -- Hallvard

1 0

Re: (ITS#5893) test scripts should stop immediately if slapd crashed
by ando＠sys-net.it 10 Feb '09

10 Feb '09

Howard Chu wrote: > Pierangelo Masarati wrote: >> hyc(a)symas.com wrote: >> >>> I saw that, but it seems that multiple -i options work. >>> -i !xx -i yy >> >> Yes, it works. The test becomes waaaaaay too verbose, though. It'd be >> nicer to have the possibility to limit the error message to the first >> occurrence, when it is intended. > > Yes, I also patched slapd-bind.c in my tree, forgot to mention that: > @@ -344,7 +348,7 @@ > /* if ignore.. */ > if ( first ) { > /* only log if first occurrence */ > - if ( force < 2 || first == 1 ) { > + if ( first == 1 ) { > tester_ldap_error( ld, "ldap_sasl_bind_s", NULL ); > } > rc = LDAP_SUCCESS; I've added another modifier, "*", that makes testers ignore errors and only log the first occurrence. I'm about to commit it. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5893) test scripts should stop immediately if slapd crashed
by hyc＠symas.com 10 Feb '09

10 Feb '09

Pierangelo Masarati wrote: > hyc(a)symas.com wrote: > >> I saw that, but it seems that multiple -i options work. >> -i !xx -i yy > > Yes, it works. The test becomes waaaaaay too verbose, though. It'd be > nicer to have the possibility to limit the error message to the first > occurrence, when it is intended. Yes, I also patched slapd-bind.c in my tree, forgot to mention that: @@ -344,7 +348,7 @@ /* if ignore.. */ if ( first ) { /* only log if first occurrence */ - if ( force < 2 || first == 1 ) { + if ( first == 1 ) { tester_ldap_error( ld, "ldap_sasl_bind_s", NULL ); } rc = LDAP_SUCCESS; -- -- 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#5893) test scripts should stop immediately if slapd crashed
by ando＠sys-net.it 10 Feb '09

10 Feb '09

hyc(a)symas.com wrote: > I saw that, but it seems that multiple -i options work. > -i !xx -i yy Yes, it works. The test becomes waaaaaay too verbose, though. It'd be nicer to have the possibility to limit the error message to the first occurrence, when it is intended. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5931) back-meta crashes with syncrepl data
by ando＠sys-net.it 10 Feb '09

10 Feb '09

ando(a)sys-net.it wrote: > This won't probably be as easy as I expected: back-meta does not check, > parse or return entry controls. This needs to be fixed as well. My fault: back-meta does. However, something strange is happening: - in some cases, while looping for attribute values, back-meta incorrectly treates entry controls (right after the SearchResultEntry message) as yet another attribute name/values set - in other cases things just go fine I'm trying to modify the code in order to compute the size of the SearchResultEntry portion of the message, but again, in some cases, the size is computed incorrectly: the computed length is 4 octets shorter than what's actually in the packet. One issue seems to be related to the fact that when ber_skip_tag() checks if the length it's computed fits in the ber by calling ber_pvt_ber_remaining(), it doesn't count that earlier calls to ber_read() moved the ber_ptr forward. The original ber_ptr should be saved. I don't believe messages are encoded incorrectly, so I must be doing something wrong in decoding them... 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5613) slapd determines hostname by PTR even if host url defined, breaking ServerID
by hyc＠symas.com 10 Feb '09

10 Feb '09

joe(a)julianfamily.org wrote: > Full_Name: Joe Julian > Version: 2.4.10 > OS: Linux (Fedora 7 distribution) > URL: > Submission from: (NULL) (68.178.24.202) > > > Description of problem: > slapd is called with "-h ldap://ldap1.domain.dom" where ldap1 is a CNAME for > the > actual server name "moe.domain.dom" and "-h ldap://ldap2.domain.dom" for > "curly.domain.dom". > > The cn=config entries for olcServerID are "1 ldap://ldap1.domain.dom" and "2 > ldap://ldap2.domain.dom" > > In config_generic (bconfig.c) case CFG_SERVERID lud->lud_host is compared with > global_host. As the PTR record for moe is moe.domain.dom and not > ldap1.domain.dom, moe does not get assigned a serverID. The same is true for > curly. > Expected results: > the serverID should be selected (in part) based on the "-h" url configuration > matching an olcServerID entry The listener URLs specified with -h are now being compared. The fix is in HEAD, please test. Thanks. -- -- 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#5853) LDAP search crashes when chasing multiple referrals
by hyc＠symas.com 10 Feb '09

10 Feb '09

hyc(a)symas.com wrote: > And yet another approach is simply to bump up each lconn's refcnt, the same > way request.c:ldap_new_connection() does, to prevent them from getting freed > prematurely. This latter approach would be simplest, except it requires > calling ldap_free_connection() to actually decrement the refcnt, and that > requires more mutex manipulation for the libldap_r version. (I haven't looked > too deeply into the lock dependencies yet, it may actually be simpler.) I opted for this approach, now checked into HEAD. Please test. -- -- 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#5893) test scripts should stop immediately if slapd crashed
by hyc＠symas.com 10 Feb '09

10 Feb '09

Pierangelo Masarati wrote: > hyc(a)symas.com wrote: >> michael(a)stroeder.com wrote: >>> Full_Name: karlsruhe >>> Version: HEAD >>> OS: Linux >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (84.163.100.169) >>> >>> >>> Currently test039-glue-ldap-concurrency fails with a lot of these messages (see >>> below). Maybe the test scripts could be modified to detect this situation and >>> stop immediately. >> Normally the tester programs will stop immediately on any error. test036 and >> test039 invoke slapd-tester with -FF which causes slapd-bind to ignore errors. >> (Note that test008 doesn't use -FF.) >> >> Seems to me that test036/039 would both work fine if they just added -i >> INVALID_CREDENTIALS to the TESTER invocation, instead of using -FF. >> >> Ando, what do you think? > > Not right now: -i is already used with negation ("!"). Negation needs > to move on a per-value basis, or something like that (if I0m reading > that code fine). I'll look at it, maybe later. I saw that, but it seems that multiple -i options work. -i !xx -i yy -- -- 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#5893) test scripts should stop immediately if slapd crashed
by ando＠sys-net.it 10 Feb '09

10 Feb '09

hyc(a)symas.com wrote: > michael(a)stroeder.com wrote: >> Full_Name: karlsruhe >> Version: HEAD >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (84.163.100.169) >> >> >> Currently test039-glue-ldap-concurrency fails with a lot of these messages (see >> below). Maybe the test scripts could be modified to detect this situation and >> stop immediately. > > Normally the tester programs will stop immediately on any error. test036 and > test039 invoke slapd-tester with -FF which causes slapd-bind to ignore errors. > (Note that test008 doesn't use -FF.) > > Seems to me that test036/039 would both work fine if they just added -i > INVALID_CREDENTIALS to the TESTER invocation, instead of using -FF. > > Ando, what do you think? Not right now: -i is already used with negation ("!"). Negation needs to move on a per-value basis, or something like that (if I0m reading that code fine). I'll look at it, maybe later. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5853) LDAP search crashes when chasing multiple referrals
by hyc＠symas.com 09 Feb '09

09 Feb '09

This is some extremely ugly code. My first instinct is to rewrite it to eliminate the recursion but I have a feeling that may be too drastic a change. Another thought is to alter wait4msg/try_read1msg's parameter list to specify which lconn to start from, and order the list such that the recursive calls can only iterate over the newest lconn structures. That would prevent them from freeing lconns that are currently being referenced by a prior caller. (That would also prevent them from parsing any received data that's ready on other connections, until the Bind on the new referral connection completes. So this may needlessly serialize some work and decrease overall throughput when references are interleaved in a larger result set.) And yet another approach is simply to bump up each lconn's refcnt, the same way request.c:ldap_new_connection() does, to prevent them from getting freed prematurely. This latter approach would be simplest, except it requires calling ldap_free_connection() to actually decrement the refcnt, and that requires more mutex manipulation for the libldap_r version. (I haven't looked too deeply into the lock dependencies yet, it may actually be simpler.) -- -- 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#5853) LDAP search crashes when chasing multiple referrals
by hyc＠symas.com 09 Feb '09

09 Feb '09

Judging from the stack trace, this appears to be the same as #5743. Since there's more info here, I'll close the older one as a dup of this one. -- -- 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#5925
by hyc＠symas.com 09 Feb '09

09 Feb '09

tchemineau(a)linagora.com wrote: > I confirm that we can not create subordinate configs dynamically in > cn=config now. I used a previously build version to realize it, just > for testing it. > > There is still errors with slaptest, even on slapd.d. Same errors when > I want to start OpenLDAP. Thanks, now fixed. -- -- 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#5893) test scripts should stop immediately if slapd crashed
by hyc＠symas.com 09 Feb '09

09 Feb '09

michael(a)stroeder.com wrote: > Full_Name: karlsruhe > Version: HEAD > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.163.100.169) > > > Currently test039-glue-ldap-concurrency fails with a lot of these messages (see > below). Maybe the test scripts could be modified to detect this situation and > stop immediately. Normally the tester programs will stop immediately on any error. test036 and test039 invoke slapd-tester with -FF which causes slapd-bind to ignore errors. (Note that test008 doesn't use -FF.) Seems to me that test036/039 would both work fine if they just added -i INVALID_CREDENTIALS to the TESTER invocation, instead of using -FF. Ando, what do you think? -- -- 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#5935) segfault in syncrepl.c when replacing olcSyncrepl values by syncrepl on cn=config
by hyc＠symas.com 09 Feb '09

09 Feb '09

jclarke(a)linagora.com wrote: > Full_Name: Jonathan Clarke > Version: RE24 > OS: CentOS 5.2 x64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (213.41.243.192) > > > Hi all, > > We have encountered a segfault that occurs in syncrepl.c, on line 1449 (from a > checkout of RE24 today). > > This occurs during replication of cn=config, by a thread in do_syncrepl on > rid=999. Syncrepl pulls in new values for olcSyncRepl on cn=config. This deletes > the configuration for rid=999, and adds configuration for rid=001 and rid=002. Thanks for the report, now fixed in HEAD. > > Some debugging (lots) showed the following. > > This thread enters syncrepl_config() 3 times: > 1) Delete rid=999. This detects this syncrepl is running, and sets si->si_ctype > = 0 (as described in the comments in syncrepl.c line 4358). si is not freed, > since it's running. The c->be->be_syncinfo->si_cookieState is freed (line > 4564). > 2) Add rid=001 > 3) Add rid=002 > > Back in syncrepl.c on line 1449, the "final delete cleanup" looks for it's own > si in be->be_syncinfo. It of course doesn't find it (the config is deleted), and > segfaults when sip = null. > > We have tried changing these lines to: > for ( sip =&be->be_syncinfo; sip != NULL || *sip != si; sip =&(*sip)->si_next > ); > if (sip) { > *sip = si->si_next; > } > > However, we then encounter another segfault on line 1448, involving > be->be_syncinfo->si_cookieState, which was freed... It's a bit too much for us > at this point, do you have any more ideas? > > > -- -- 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#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by ando＠sys-net.it 09 Feb '09

09 Feb '09

Michael Ströder wrote: > As said I'm really concerned about security aspects: Because if the > hostname in the LDAP URL is absent there's absolutely no possibility to > check for DNS spoofing and the LDAP client would possibly happily send > its credentials to a rogue server, even with TLS or Kerberos. Think > twice before implementing this. > > Frankly I'd vote against stuffing this into standard function > ldap_initialize(). Using this without further pre-caution (like > user-interaction) is broken in a similar way like chasing LDAPv3 > referrals at the client side. But stuffing this in ldap_initialize(3) has the great advance of allowing to inject this feature in clients without the need to modify them, just reconfiguring. The use of a URL extension should make it clear that one intends to use the feature, and avoid unintentional (e.g. misconfiguration) uses. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: authzTo ACL check for wrong principal (ITS#5555)
by ando＠sys-net.it 09 Feb '09

09 Feb '09

Gavin Henry wrote: >> On Mon, Jun 16, 2008 at 02:29:21PM +0000, Andrew Findlay wrote: >> >>> Thus I think my original report was wrong. This is a documentation >>> issue, not a bug. >> I have uploaded a suggested set of patches to make the behaviour >> clearer: >> >> ftp://ftp.openldap.com/incoming/andrew.findlay-20080616.patch >> >> The patch is against 2.4.10 >> >> It might be better still to factor out the concept of proxy >> authorisation and its control from the SASL authz mechanism, as it >> applies also to the LDAP Proxied Authorization Control. >> I have not done this as I was unsure where best to put it. > > Hi Ando, > > If you get a chance at some point, could you review this patch and I'll apply it > etc. After a quick look, it seems to be a good starting point. I'd be a little bit more careful about wording: "proxyAuthz" should probably be "proxied authorization"; the first time it is mentioned, a reference to RFC4370 should be present, both in slapd.access(5) and in the Admin Guide (as in the SASL section). Also, in the contribution to the Admin Guide it is sometimes referred to as the "proxy facility"; I'd rather use "proxied authorization facility" or better "proxied authorization control". Finally, the patch seems to correctly explain what is required in order to authorize. I'd add a strong comment on the importance to protect authzFrom and especially authzTo from malicious writes, that could result in lesser privileged identities to modify their own entry in order to be able to self-authorize as higher privileged identities. Administrators should be warned as they start reading about this feature. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5934) NULL pointer usage in ldap_new_connection(), causes segmentation fault
by hyc＠symas.com 09 Feb '09

09 Feb '09

bplank(a)gta.com wrote: > Full_Name: Brad Plank > Version: 2.4.13 > OS: FreeBSD > URL: ftp://ftp.openldap.org/incoming/brad-plank-090209.patch > Submission from: (NULL) (199.120.225.110) > Thanks for the report, now fixed in HEAD and RE24. > NULL pointer usage in: > LDAPConn * > ldap_new_connection( LDAP *ld, LDAPURLDesc **srvlist, int use_ldsb, > int connect, LDAPreqinfo *bind ) > > ... > if ( lc->lconn_server->lud_exts ) { > ... > > The below patch is to fix this issue, since the pointer "lconn_server" should > only be used when "connect" is non-zero: > > ================================================================== > > --- libraries/libldap/request.c.orig 2008-11-07 20:15:17.000000000 -0500 > +++ libraries/libldap/request.c 2009-02-09 11:01:56.000000000 -0500 > @@ -452,9 +452,9 @@ ldap_new_connection( LDAP *ld, LDAPURLDe > ldap_pvt_thread_mutex_unlock(&ld->ld_conn_mutex ); > #endif > > - if ( lc->lconn_server->lud_exts ) { > -#ifdef HAVE_TLS > if ( connect ) { > +#ifdef HAVE_TLS > + if ( lc->lconn_server->lud_exts ) { > int rc, ext = find_tls_ext( lc->lconn_server ); > if ( ext ) { > LDAPConn *savedefconn; > > ================================================================== > > I, Brad Plank, hereby place the following modifications to OpenLDAP Software > (and only these modifications) into the public domain. Hence, these > modifications may be freely used and/or redistributed for any purpose with or > without attribution and/or other notice. > > > -- -- 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#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by ando＠sys-net.it 09 Feb '09

09 Feb '09

philippe.eychart(a)informatique.gov.pf wrote: > michael(a)stroeder.com wrote: >> Such an extension would be feasible. But still I'm not sure whether this >> distinction is needed. Although LDAP URL with empty hostport portion are >> used internally (e.g. in ACLs) this IMHO does not affect >> ldap_initialize(). Maybe I missed something. But before implementing a >> patch this should be clarified. > > Do you suggest that an empty hostport (as ldap_initialize() arg) could mean > that a SRV search is needed ? > But this will reduce the search in the default domain name, won't it ? > So, how to produce a search in another specific domain name when wished ? > Where (in the URI) to appoint the root ("dc=my,dc=domain") or the explicit > domain name ("my.domain") for the search domain ?... > > Secondarily, how to specify the present meaning "this LDAP server" if we use > this empty hostport syntaxe for SRV seach ? (A SRV search could respond when > the user think to request his local LDAP server ...) OpenLDAP clients do the following: empty hostport, empty DN: localhost, default port empty hostport, non-empty DN: SRV what might be missing IMHO is: use domain to specify SRV however, I don't see any special need for it, as domain can always be put in DN form. I don't know if there's need for a form that asks to use SRV to discover the server for the default SUFFIX. In order to avoid issues, I recommend using something like x-dnssrv={<domain>|<DN>} where <DN> is restricted to the domain component sequence form. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

RE: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by philippe.eychart＠informatique.gov.pf 09 Feb '09

09 Feb '09

michael(a)stroeder.com wrote: > Such an extension would be feasible. But still I'm not sure whether this > distinction is needed. Although LDAP URL with empty hostport portion are > used internally (e.g. in ACLs) this IMHO does not affect > ldap_initialize(). Maybe I missed something. But before implementing a > patch this should be clarified. Do you suggest that an empty hostport (as ldap_initialize() arg) could mean that a SRV search is needed ? But this will reduce the search in the default domain name, won't it ? So, how to produce a search in another specific domain name when wished ? Where (in the URI) to appoint the root ("dc=my,dc=domain") or the explicit domain name ("my.domain") for the search domain ?... Secondarily, how to specify the present meaning "this LDAP server" if we use this empty hostport syntaxe for SRV seach ? (A SRV search could respond when the user think to request his local LDAP server ...) --- PE

1 0

(ITS#5935) segfault in syncrepl.c when replacing olcSyncrepl values by syncrepl on cn=config
by jclarke＠linagora.com 09 Feb '09

09 Feb '09

Full_Name: Jonathan Clarke Version: RE24 OS: CentOS 5.2 x64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.41.243.192) Hi all, We have encountered a segfault that occurs in syncrepl.c, on line 1449 (from a checkout of RE24 today). This occurs during replication of cn=config, by a thread in do_syncrepl on rid=999. Syncrepl pulls in new values for olcSyncRepl on cn=config. This deletes the configuration for rid=999, and adds configuration for rid=001 and rid=002. Some debugging (lots) showed the following. This thread enters syncrepl_config() 3 times: 1) Delete rid=999. This detects this syncrepl is running, and sets si->si_ctype = 0 (as described in the comments in syncrepl.c line 4358). si is not freed, since it's running. The c->be->be_syncinfo->si_cookieState is freed (line 4564). 2) Add rid=001 3) Add rid=002 Back in syncrepl.c on line 1449, the "final delete cleanup" looks for it's own si in be->be_syncinfo. It of course doesn't find it (the config is deleted), and segfaults when sip = null. We have tried changing these lines to: for ( sip = &be->be_syncinfo; sip != NULL || *sip != si; sip = &(*sip)->si_next ); if (sip) { *sip = si->si_next; } However, we then encounter another segfault on line 1448, involving be->be_syncinfo->si_cookieState, which was freed... It's a bit too much for us at this point, do you have any more ideas?

1 0

(ITS#5934) NULL pointer usage in ldap_new_connection(), causes segmentation fault
by bplank＠gta.com 09 Feb '09

09 Feb '09

Full_Name: Brad Plank Version: 2.4.13 OS: FreeBSD URL: ftp://ftp.openldap.org/incoming/brad-plank-090209.patch Submission from: (NULL) (199.120.225.110) NULL pointer usage in: LDAPConn * ldap_new_connection( LDAP *ld, LDAPURLDesc **srvlist, int use_ldsb, int connect, LDAPreqinfo *bind ) ... if ( lc->lconn_server->lud_exts ) { ... The below patch is to fix this issue, since the pointer "lconn_server" should only be used when "connect" is non-zero: ================================================================== --- libraries/libldap/request.c.orig 2008-11-07 20:15:17.000000000 -0500 +++ libraries/libldap/request.c 2009-02-09 11:01:56.000000000 -0500 @@ -452,9 +452,9 @@ ldap_new_connection( LDAP *ld, LDAPURLDe ldap_pvt_thread_mutex_unlock( &ld->ld_conn_mutex ); #endif - if ( lc->lconn_server->lud_exts ) { -#ifdef HAVE_TLS if ( connect ) { +#ifdef HAVE_TLS + if ( lc->lconn_server->lud_exts ) { int rc, ext = find_tls_ext( lc->lconn_server ); if ( ext ) { LDAPConn *savedefconn; ================================================================== I, Brad Plank, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#5931) back-meta crashes with syncrepl data
by ali.pouya＠free.fr 09 Feb '09

09 Feb '09

Yes, I confirm that now the slapd from HEAD simply ignores the intermediate response type. So I can go forward on my projet :-) In this project I do not bother about the contextCSN of my replica because it is managed by another master. Thanks a lot for this rapid fix. Best Regards Ali Selon Pierangelo Masarati <ando(a)sys-net.it>: > Slapd in HEAD no longer crashes when receiving intermediate response. > It rather complains about an unsupported response message. I'm now > working at correctly handling it. > > p.

1 0

Re: (ITS#5930) Problem while making the build
by quanah＠zimbra.com 09 Feb '09

09 Feb '09

--On Monday, February 09, 2009 7:44 AM +0000 bhupi.iit(a)gmail.com wrote: > Full_Name: Bhupinder > Version: 2.4.11 > OS: Solaris SunOS.5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (149.77.167.165) > > > setenv LD_LIBRARY_PATH /usr/local/BerkeleyDB/lib > setenv CPPFLAGS -I/usr/local/BerkeleyDB/include/ > > ./configure > make depend > make > > while 'mak'ing i get the following error. > .. > .. > .. > /bin/sh ../..//libtool --mode=compile cc -g -I../../include > -I../../include -I/usr/local/BerkeleyDB/include/ -DLDAP_LIBRARY -c > tls.c cc -g -I../../include -I../../include > -I/usr/local/BerkeleyDB/include/ -DLDAP_LIBRARY -c tls.c -KPIC -DPIC -o > .libs/tls.o > "tls.c", line 102: syntax error before or at: gnutls_kx_algorithm_t > "tls.c", line 112: syntax error before or at: typedef > "tls.c", line 114: syntax error before or at: > gnutls_certificate_credentials_t "tls.c", line 127: syntax error before > or at: typedef > "tls.c", line 128: syntax error before or at: tls_ctx > "tls.c", line 189: member cannot be function: ldap_pvt_tls_ctx_free > "tls.c", line 189: warning: syntax requires ";" after last struct/union > member "tls.c", line 189: syntax error before or at: { > "tls.c", line 191: syntax error before or at: tls_ctx > "tls.c", line 211: member cannot be function: tls_ctx_new > "tls.c", line 211: warning: syntax requires ";" after last struct/union > member "tls.c", line 211: syntax error before or at: { > "tls.c", line 230: syntax error before or at: * > "tls.c", line 231: member cannot be function: tls_ctx_ref > "tls.c", line 231: warning: syntax requires ";" after last struct/union > member "tls.c", line 242: warning: syntax requires ";" after last > struct/union member "tls.c", line 262: warning: syntax requires ";" after > last struct/union member "tls.c", line 275: syntax error before or at: * > "tls.c", line 276: member cannot be function: tls_session_free > "tls.c", line 276: warning: syntax requires ";" after last struct/union > member "tls.c", line 285: syntax error before or at: * > "tls.c", line 285: warning: undefined or missing type for: char > "tls.c", line 286: member cannot be function: tls_parse_ciphers > "tls.c", line 286: warning: syntax requires ";" after last struct/union > member "tls.c", line 289: warning: syntax requires ";" after last > struct/union member "tls.c", line 289: syntax error before or at: = > "tls.c", line 292: syntax error before or at: num > "tls.c", line 314: warning: syntax requires ";" after last struct/union > member "tls.c", line 350: zero-sized struct/union > "tls.c", line 352: warning: old-style declaration or incorrect type for: > ptr "tls.c", line 352: warning: old-style declaration or incorrect type > for: len "tls.c", line 352: warning: syntax error: empty declaration > "tls.c", line 353: warning: old-style declaration or incorrect type for: > end "tls.c", line 354: undefined symbol: nkx > "tls.c", line 354: can not declare variably modified type at file scope > "tls.c", line 354: warning: old-style declaration or incorrect type for: > kx "tls.c", line 354: warning: {}-enclosed initializer required > "tls.c", line 354: too many array initializers > "tls.c", line 354: warning: variable length array can not be initialized: > kx "tls.c", line 355: undefined symbol: ncipher > "tls.c", line 355: can not declare variably modified type at file scope > "tls.c", line 355: warning: old-style declaration or incorrect type for: > cipher "tls.c", line 355: warning: {}-enclosed initializer required > "tls.c", line 355: too many array initializers > "tls.c", line 355: warning: variable length array can not be initialized: > cipher > "tls.c", line 356: undefined symbol: nmac > "tls.c", line 356: can not declare variably modified type at file scope > "tls.c", line 356: warning: old-style declaration or incorrect type for: > mac "tls.c", line 356: warning: {}-enclosed initializer required > "tls.c", line 356: too many array initializers > "tls.c", line 356: warning: variable length array can not be initialized: > mac "tls.c", line 357: warning: old-style declaration or incorrect type > for: ctx "tls.c", line 357: syntax error before or at: -> > "tls.c", line 357: warning: old-style declaration or incorrect type for: > kx_list > "tls.c", line 357: warning: improper pointer/integer combination: op "=" > "tls.c", line 358: warning: old-style declaration or incorrect type for: > ctx "tls.c", line 358: syntax error before or at: -> > "tls.c", line 358: warning: old-style declaration or incorrect type for: > cipher_list > "tls.c", line 358: warning: improper pointer/integer combination: op "=" > "tls.c", line 359: warning: old-style declaration or incorrect type for: > ctx "tls.c", line 359: syntax error before or at: -> > "tls.c", line 359: warning: old-style declaration or incorrect type for: > mac_list > "tls.c", line 359: warning: improper pointer/integer combination: op "=" > "tls.c", line 360: syntax error before or at: return > "tls.c", line 360: warning: syntax error: empty declaration > "tls.c", line 532: cannot recover from previous errors > cc: acomp failed for tls.c > make[2]: *** [tls.lo] Error 1 > make[2]: Leaving directory `~openldap/openldap-2.4.11/libraries/libldap' > make[1]: *** [all-common] Error 1 > make[1]: Leaving directory `~/openldap/openldap-2.4.11/libraries' > make: *** [all-common] Error 1 > > > > Please let me know if i'm doing something wrong here. Looks like it can't find your GnuTLS headers/libs, at a guess. In any case, this isn't an OpenLDAP bug. Please use openldap-software for further help with building OpenLDAP. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5931) back-meta crashes with syncrepl data
by ando＠sys-net.it 09 Feb '09

09 Feb '09

ando(a)sys-net.it wrote: > Slapd in HEAD no longer crashes when receiving intermediate response. > It rather complains about an unsupported response message. I'm now > working at correctly handling it. This won't probably be as easy as I expected: back-meta does not check, parse or return entry controls. This needs to be fixed as well. I notice that back-ldap and back-meta use ldap_first_entry() to parse the entry. Syncrepl client-side code uses a ldap_get_entry_controls() and explicit entry parsing. Probably we need to abstract what syncrepl does in a new libldap call that parses an entry and its controls, and use it as appropriate. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Need bug list for openldap-2.2.24 release.
by kalyan tej 09 Feb '09

09 Feb '09

Hi Folks, I am new to openldap ,I'd like to know the list of software bugs in openldap-2.2.24 release. I chose openldap-2.2.24 because my libc version is 2.3.3.It would be of great help to me if someone can provide me with the major list of bugs in the mentioned release and/or fixes . Thanks in advance, -Kalyan Tej

2 1

Re: (ITS#5931) back-meta crashes with syncrepl data
by ando＠sys-net.it 09 Feb '09

09 Feb '09

Slapd in HEAD no longer crashes when receiving intermediate response. It rather complains about an unsupported response message. I'm now working at correctly handling it. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5931) back-meta crashes with syncrepl data
by ando＠sys-net.it 09 Feb '09

09 Feb '09

ali.pouya(a)free.fr wrote: > I try to connect a RefreshAndPersist syncrepl client to a sync provider slapd > through an intermediate back-meta slapd in order tu use its RWM features. > The search entries are propagated without problem. But back-meta crashes each > time it receives the LDAP_RES_INTERMEDIATE response time from the sync provider > reproducing the following message : > > read1msg: ld 0x9f29550 msgid 2 message type intermediate > slapd: search.c:1460: meta_back_search: Assertion `0' failed. > Abandon Back-beta (and probably back-ldap) need to be able to recognize intermediate response messages, as they are part of the protocol. Probably, it would be a good idea to detect unrecognized response messages and handle them nicely. > I think this would be a useful feature to be able to make replicas that are > different from the master. > May be if this response time is propagated as is this type of synchronization > will be possible ? I'd notice that this type of operation might be less than ideal, since a proxied refreshAndPersist operation will keep one thread of the proxy busy all times waiting for further responses. > I am aware that connection to more thant one targets through back-meta may be > meaningless. In that case you could use back-ldap with slapo-rwm. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5933) back-meta crashes with syncrepl data
by ali.pouya＠free.fr 09 Feb '09

09 Feb '09

Full_Name: Ali Pouya Version: 2.4.13 OS: Linux 2.6 (Fedora) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (145.242.11.3) I try to connect a RefreshAndPersist syncrepl client to a sync provider slapd through an intermediate back-meta slapd in order tu use its RWM features. The search entries are propagated without problem. But back-meta crashes each time it receives the LDAP_RES_INTERMEDIATE response time from the sync provider reproducing the following message : read1msg: ld 0x9f29550 msgid 2 message type intermediate slapd: search.c:1460: meta_back_search: Assertion `0' failed. Abandon I think this would be a useful feature to be able to make replicas that are different from the master. May be if this response time is propagated as is this type of synchronization will be possible ? I am aware that connection to more thant one targets through back-meta may be meaningless. Thanks for your help Best Redgards Ali Pouya

1 0

(ITS#5932) back-meta crashes with syncrepl data
by ali.pouya＠free.fr 09 Feb '09

09 Feb '09

Full_Name: Ali Pouya Version: 2.4.13 OS: Linux 2.6 (Fedora) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (145.242.11.4) I try to connect a RefreshAndPersist syncrepl client to a sync provider slapd through an intermediate back-meta slapd in order tu use its RWM features. The search entries are propagated without problem. But back-meta crashes each time it receives the LDAP_RES_INTERMEDIATE response time from the sync provider reproducing the following message : read1msg: ld 0x9f29550 msgid 2 message type intermediate slapd: search.c:1460: meta_back_search: Assertion `0' failed. Abandon I think this would be a useful feature to be able to make replicas that are different from the master. May be if this response time is propagated as is this type of synchronization will be possible ? I am aware that connection to more thant one targets through back-meta may be meaningless. Thanks for your help Best Redgards Ali Pouya

1 0

(ITS#5931) back-meta crashes with syncrepl data
by ali.pouya＠free.fr 09 Feb '09

09 Feb '09

Full_Name: Ali Pouya Version: 2.4.13 OS: Linux 2.6 (Fedora) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (145.242.11.4) I try to connect a RefreshAndPersist syncrepl client to a sync provider slapd through an intermediate back-meta slapd in order tu use its RWM features. The search entries are propagated without problem. But back-meta crashes each time it receives the LDAP_RES_INTERMEDIATE response time from the sync provider reproducing the following message : read1msg: ld 0x9f29550 msgid 2 message type intermediate slapd: search.c:1460: meta_back_search: Assertion `0' failed. Abandon I think this would be a useful feature to be able to make replicas that are different from the master. May be if this response time is propagated as is this type of synchronization will be possible ? I am aware that connection to more thant one targets through back-meta may be meaningless. Thanks for your help Best Redgards Ali Pouya

1 0

Re: (ITS#5929) 'make test' uses installed libldap_r/liblber
by hyc＠symas.com 09 Feb '09

09 Feb '09

hyc(a)symas.com wrote: > Hallvard B Furuseth wrote: >> hyc(a)symas.com writes: >>>> Seems to me we need to reinstate those commands. >>> Fixed now in HEAD >> Didn't help. But I'm not sure it was necessary anyway - after all it >> did find the libraries when I did not set LDPATH, even though there >> were no symlinks. Something is being quite magical. >> > Eh. I'd forgotten. The libtool script generates a wrapper script for each > binary that sets LD_LIBRARY_PATH already. So really we should remove the > LD_LIBRARY_PATH export from scripts/defines.sh. > > And that means your problem is a libtool problem. I played with this a bit more. The situation is this: The ELF linker doesn't store the absolute pathnames of dependent dynamic libraries, so it relies entirely on compiled-in runpaths and environment runpaths. Our default invocations of libtool never supply a runpath. Since you're adding one explicitly to your build, without any other settings, your runpath is the only one in effect. Since you're setting both -L and -rpath, your binaries will be linked and executed against your installed libs, regardless of what the libtool wrapper script does. If you want this to work you'll have to provide both the build directory and your installed directory in your -rpath. The symlinks would then help a little, because you only need to set one build rpath instead of 3. Go ahead and restore the build rules in your source tree to set the symlinks if you want them. At the moment it looks like they're not generally useful, and I'm tired of committing/reverting, so I'm not touching those files any more today. -- -- 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#5929) 'make test' uses installed libldap_r/liblber
by hyc＠symas.com 08 Feb '09

08 Feb '09

Hallvard B Furuseth wrote: > hyc(a)symas.com writes: >>> Seems to me we need to reinstate those commands. >> Fixed now in HEAD > > Didn't help. But I'm not sure it was necessary anyway - after all it > did find the libraries when I did not set LDPATH, even though there > were no symlinks. Something is being quite magical. > Eh. I'd forgotten. The libtool script generates a wrapper script for each binary that sets LD_LIBRARY_PATH already. So really we should remove the LD_LIBRARY_PATH export from scripts/defines.sh. And that means your problem is a libtool problem. -- -- 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#5930) Problem while making the build
by bhupi.iit＠gmail.com 08 Feb '09

08 Feb '09

Full_Name: Bhupinder Version: 2.4.11 OS: Solaris SunOS.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (149.77.167.165) setenv LD_LIBRARY_PATH /usr/local/BerkeleyDB/lib setenv CPPFLAGS -I/usr/local/BerkeleyDB/include/ ./configure make depend make while 'mak'ing i get the following error. .. .. .. /bin/sh ../..//libtool --mode=compile cc -g -I../../include -I../../include -I/usr/local/BerkeleyDB/include/ -DLDAP_LIBRARY -c tls.c cc -g -I../../include -I../../include -I/usr/local/BerkeleyDB/include/ -DLDAP_LIBRARY -c tls.c -KPIC -DPIC -o .libs/tls.o "tls.c", line 102: syntax error before or at: gnutls_kx_algorithm_t "tls.c", line 112: syntax error before or at: typedef "tls.c", line 114: syntax error before or at: gnutls_certificate_credentials_t "tls.c", line 127: syntax error before or at: typedef "tls.c", line 128: syntax error before or at: tls_ctx "tls.c", line 189: member cannot be function: ldap_pvt_tls_ctx_free "tls.c", line 189: warning: syntax requires ";" after last struct/union member "tls.c", line 189: syntax error before or at: { "tls.c", line 191: syntax error before or at: tls_ctx "tls.c", line 211: member cannot be function: tls_ctx_new "tls.c", line 211: warning: syntax requires ";" after last struct/union member "tls.c", line 211: syntax error before or at: { "tls.c", line 230: syntax error before or at: * "tls.c", line 231: member cannot be function: tls_ctx_ref "tls.c", line 231: warning: syntax requires ";" after last struct/union member "tls.c", line 242: warning: syntax requires ";" after last struct/union member "tls.c", line 262: warning: syntax requires ";" after last struct/union member "tls.c", line 275: syntax error before or at: * "tls.c", line 276: member cannot be function: tls_session_free "tls.c", line 276: warning: syntax requires ";" after last struct/union member "tls.c", line 285: syntax error before or at: * "tls.c", line 285: warning: undefined or missing type for: char "tls.c", line 286: member cannot be function: tls_parse_ciphers "tls.c", line 286: warning: syntax requires ";" after last struct/union member "tls.c", line 289: warning: syntax requires ";" after last struct/union member "tls.c", line 289: syntax error before or at: = "tls.c", line 292: syntax error before or at: num "tls.c", line 314: warning: syntax requires ";" after last struct/union member "tls.c", line 350: zero-sized struct/union "tls.c", line 352: warning: old-style declaration or incorrect type for: ptr "tls.c", line 352: warning: old-style declaration or incorrect type for: len "tls.c", line 352: warning: syntax error: empty declaration "tls.c", line 353: warning: old-style declaration or incorrect type for: end "tls.c", line 354: undefined symbol: nkx "tls.c", line 354: can not declare variably modified type at file scope "tls.c", line 354: warning: old-style declaration or incorrect type for: kx "tls.c", line 354: warning: {}-enclosed initializer required "tls.c", line 354: too many array initializers "tls.c", line 354: warning: variable length array can not be initialized: kx "tls.c", line 355: undefined symbol: ncipher "tls.c", line 355: can not declare variably modified type at file scope "tls.c", line 355: warning: old-style declaration or incorrect type for: cipher "tls.c", line 355: warning: {}-enclosed initializer required "tls.c", line 355: too many array initializers "tls.c", line 355: warning: variable length array can not be initialized: cipher "tls.c", line 356: undefined symbol: nmac "tls.c", line 356: can not declare variably modified type at file scope "tls.c", line 356: warning: old-style declaration or incorrect type for: mac "tls.c", line 356: warning: {}-enclosed initializer required "tls.c", line 356: too many array initializers "tls.c", line 356: warning: variable length array can not be initialized: mac "tls.c", line 357: warning: old-style declaration or incorrect type for: ctx "tls.c", line 357: syntax error before or at: -> "tls.c", line 357: warning: old-style declaration or incorrect type for: kx_list "tls.c", line 357: warning: improper pointer/integer combination: op "=" "tls.c", line 358: warning: old-style declaration or incorrect type for: ctx "tls.c", line 358: syntax error before or at: -> "tls.c", line 358: warning: old-style declaration or incorrect type for: cipher_list "tls.c", line 358: warning: improper pointer/integer combination: op "=" "tls.c", line 359: warning: old-style declaration or incorrect type for: ctx "tls.c", line 359: syntax error before or at: -> "tls.c", line 359: warning: old-style declaration or incorrect type for: mac_list "tls.c", line 359: warning: improper pointer/integer combination: op "=" "tls.c", line 360: syntax error before or at: return "tls.c", line 360: warning: syntax error: empty declaration "tls.c", line 532: cannot recover from previous errors cc: acomp failed for tls.c make[2]: *** [tls.lo] Error 1 make[2]: Leaving directory `~openldap/openldap-2.4.11/libraries/libldap' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `~/openldap/openldap-2.4.11/libraries' make: *** [all-common] Error 1 Please let me know if i'm doing something wrong here. Thanks bhupi

1 0

Re: (ITS#5929) 'make test' uses installed libldap_r/liblber
by h.b.furuseth＠usit.uio.no 08 Feb '09

08 Feb '09

hyc(a)symas.com writes: >> Seems to me we need to reinstate those commands. > > Fixed now in HEAD Didn't help. But I'm not sure it was necessary anyway - after all it did find the libraries when I did not set LDPATH, even though there were no symlinks. Something is being quite magical. -- Hallvard

1 0

Re: (ITS#5929) 'make test' uses installed libldap_r/liblber
by hyc＠symas.com 08 Feb '09

08 Feb '09

hyc(a)symas.com wrote: > Hmm. The export in defines.sh is useless now, because build/lib-shared.mk's > rules to symlink the shared libraries into place was removed in rev 1.16. > > (See the lib-shared/mk CVS log...) > > Seems to me we need to reinstate those commands. > Fixed now in HEAD -- -- 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#5929) 'make test' uses installed libldap_r/liblber
by hyc＠symas.com 08 Feb '09

08 Feb '09

hyc(a)symas.com wrote: > Hallvard B Furuseth wrote: >> hyc(a)symas.com writes: >>>> "make test" uses installed instead of newly built libraries, >>>> with ./configure --enable-dynamic LDFLAGS=<installed lib>. >>> Don't do that. >> Then what do I do? Some libraries OpenLDAP needs are there, including >> DB 4.4. Without LDFLAGS and corresponding CPPFLAGS I get the system's >> DB 4.3, so configure doesn't magically look in<--prefix>/lib/ on its >> own. Or with CPPFLAGS but without LDFLAGS I get DB version mismatch. >> >> I don't want to require $LD_LIBRARY_PATH to be set before running >> OpenLDAP programs, nor to mess with /etc/ld.so.conf. > > Note that scripts/defines.sh already explicitly sets LD_LIBRARY_PATH to point > at the newly built libraries. What else do you expect us to do? > Hmm. The export in defines.sh is useless now, because build/lib-shared.mk's rules to symlink the shared libraries into place was removed in rev 1.16. (See the lib-shared/mk CVS log...) Seems to me we need to reinstate those commands. -- -- 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#5927) assertion error when using pcache
by hyc＠symas.com 08 Feb '09

08 Feb '09

Michael Ströder wrote: > hyc(a)symas.com wrote: >> As an alternative, I suggest modifying slapd/ad.c to treat "=" the same as "-" >> in an option definition. Then simply adding >> attributeoption range= >> to slapd.conf will allow the values to be recognized. (With the constraint >> that '=' must be the final character in the option definition...) >> >> Let the client decide if they want to go thru the trouble of retrieving all >> the values or not. Certainly, for slapd to do it implicitly will overburden >> the (pathetically broken) AD server (otherwise they wouldn't need to break the >> value up into ranges in the first place). Indeed, doing this implicitly would >> amount to a DOS attack on the AD server. > > I strongly agree with Howard here. The work-around for "=" seems enough. > If someone really writes an app which needs the range feature it should > access AD directly. Right. This is now changed in HEAD. If an attributeoption is configured that ends with '=' then MSAD compatibility is enabled, otherwise '=' is rejected as usual. -- -- 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#5929) 'make test' uses installed libldap_r/liblber
by hyc＠symas.com 08 Feb '09

08 Feb '09

Hallvard B Furuseth wrote: > hyc(a)symas.com writes: >>> "make test" uses installed instead of newly built libraries, >>> with ./configure --enable-dynamic LDFLAGS=<installed lib>. >> Don't do that. > > Then what do I do? Some libraries OpenLDAP needs are there, including > DB 4.4. Without LDFLAGS and corresponding CPPFLAGS I get the system's > DB 4.3, so configure doesn't magically look in<--prefix>/lib/ on its > own. Or with CPPFLAGS but without LDFLAGS I get DB version mismatch. > > I don't want to require $LD_LIBRARY_PATH to be set before running > OpenLDAP programs, nor to mess with /etc/ld.so.conf. Note that scripts/defines.sh already explicitly sets LD_LIBRARY_PATH to point at the newly built libraries. What else do you expect us to do? -- -- 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#5927) assertion error when using pcache
by ando＠sys-net.it 08 Feb '09

08 Feb '09

mhardin(a)symas.com wrote: >> mhardin(a)symas.com wrote: >>> On Feb 7, 2009, at 9:21 AM, ando(a)sys-net.it wrote: >>>> mhardin(a)symas.com wrote: >>>>> Sorry for the out-of-sequence reply. I'll test and let you know >>>>> what I >>>>> find. >>>> No problem. Note that if this is the cause of this issue, and, in >>>> any >>>> case, if you have some "range" attributes in your response, you >>>> still >>>> have an issue with those values. >>> Yes. I'm not sure what to do about them in the medium term. Not >>> having slapd crash is a good first step, though :P >> Are you confirming that the original issue is fixed? > > Unfortunately not. The morning I tested the fix you checked into HEAD > and still got an assertion error in pcache at the same point when > caching group objects that contain range specifiers. I have core files > and would be happy to provide additional information if you need it. As I wrote, I only simulated receiving that type of response by modifying the name of the attribute after it was extracted by back-meta and before it was resolved. It would be interesting to see what happens when the actual response of AD is received by back-meta. In any case, since you have the core files, it would be interesting to see the attribute structure, and specifically of the a_desc member (the AttributeDescription structure). 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5927) assertion error when using pcache
by mhardin＠symas.com 08 Feb '09

08 Feb '09

On Feb 8, 2009, at 1:26 PM, Pierangelo Masarati wrote: > mhardin(a)symas.com wrote: >> On Feb 7, 2009, at 9:21 AM, ando(a)sys-net.it wrote: >>> mhardin(a)symas.com wrote: >>>> Sorry for the out-of-sequence reply. I'll test and let you know >>>> what I >>>> find. >>> No problem. Note that if this is the cause of this issue, and, in >>> any >>> case, if you have some "range" attributes in your response, you >>> still >>> have an issue with those values. >> Yes. I'm not sure what to do about them in the medium term. Not >> having slapd crash is a good first step, though :P > > Are you confirming that the original issue is fixed? Unfortunately not. The morning I tested the fix you checked into HEAD and still got an assertion error in pcache at the same point when caching group objects that contain range specifiers. I have core files and would be happy to provide additional information if you need it. > > >>> It seems that, in the spirit of >>> OpenLDAP software, we could be relatively liberal in accepting those >>> values provided we are able to consolidate them in a single entry >>> with >>> no ranges. Apparently, what the proxies could do is: >>> >>> - whenever a range is obtained in a response >>> - iteratively query the server again for the same entry, >>> - requesting only that attribute for the next block of vals >>> - incrementally build the set of values >>> - return the consolidated entry >>> >>> This MUST be configurable, and documented as a nasty, expensive and >>> unnecessary hack. >>> >> I had thought it might be possible to craft this functionality as >> an overlay (we could call it "derange" :P), but I think you're >> right- it is more appropriate that it be something configurable in >> back-meta and back-ldap. > > You can't handle that with an overlay, since the message containing > this type of response is received by the proxy backends and would > fail parsing unless handled there :). So I've learned :) > > >> This functionality is particularly interesting when one considers >> using Howard's nss_ov in conjunction with pcache and back- ldap >> communicating with directory servers that were never intended to >> handle the high loads that Unix/Linux name services can place on a >> directory server ;-) >> The high cost of the iterative searches might be mitigated through >> use of pcache. I'm thinking the searches to consolidate the >> ranged attributes would happen anyway, so better to do them in the >> proxy and cache the results than make each individual client have >> to do them. > > Yes. Another possible issue is that we'd probably need to work a > symmetric solution in those cases where a request needs values to be > broken in ranges in order to be accepted by AD. Ugh. I suppose so, although my interest in that is relatively low at this point. > > > p. > > -Matt > 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 > Fax: +39 0382 476497 > Email: ando(a)sys-net.it > ----------------------------------- >

1 0

Re: (ITS#5927) assertion error when using pcache
by ando＠sys-net.it 08 Feb '09

08 Feb '09

mhardin(a)symas.com wrote: > On Feb 7, 2009, at 9:21 AM, ando(a)sys-net.it wrote: > >> mhardin(a)symas.com wrote: >>> Sorry for the out-of-sequence reply. I'll test and let you know >>> what I >>> find. >> No problem. Note that if this is the cause of this issue, and, in any >> case, if you have some "range" attributes in your response, you still >> have an issue with those values. > > Yes. I'm not sure what to do about them in the medium term. Not having > slapd crash is a good first step, though :P Are you confirming that the original issue is fixed? >> It seems that, in the spirit of >> OpenLDAP software, we could be relatively liberal in accepting those >> values provided we are able to consolidate them in a single entry with >> no ranges. Apparently, what the proxies could do is: >> >> - whenever a range is obtained in a response >> - iteratively query the server again for the same entry, >> - requesting only that attribute for the next block of vals >> - incrementally build the set of values >> - return the consolidated entry >> >> This MUST be configurable, and documented as a nasty, expensive and >> unnecessary hack. >> > > I had thought it might be possible to craft this functionality as an > overlay (we could call it "derange" :P), but I think you're right- it > is more appropriate that it be something configurable in back-meta and > back-ldap. You can't handle that with an overlay, since the message containing this type of response is received by the proxy backends and would fail parsing unless handled there :). > This functionality is particularly interesting when one > considers using Howard's nss_ov in conjunction with pcache and back- > ldap communicating with directory servers that were never intended to > handle the high loads that Unix/Linux name services can place on a > directory server ;-) > > The high cost of the iterative searches might be mitigated through use > of pcache. I'm thinking the searches to consolidate the ranged > attributes would happen anyway, so better to do them in the proxy and > cache the results than make each individual client have to do them. Yes. Another possible issue is that we'd probably need to work a symmetric solution in those cases where a request needs values to be broken in ranges in order to be accepted by AD. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5929) 'make test' uses installed libldap_r/liblber
by h.b.furuseth＠usit.uio.no 08 Feb '09

08 Feb '09

hyc(a)symas.com writes: >> "make test" uses installed instead of newly built libraries, >> with ./configure --enable-dynamic LDFLAGS=<installed lib>. > > Don't do that. Then what do I do? Some libraries OpenLDAP needs are there, including DB 4.4. Without LDFLAGS and corresponding CPPFLAGS I get the system's DB 4.3, so configure doesn't magically look in <--prefix>/lib/ on its own. Or with CPPFLAGS but without LDFLAGS I get DB version mismatch. I don't want to require $LD_LIBRARY_PATH to be set before running OpenLDAP programs, nor to mess with /etc/ld.so.conf. -- Hallvard

1 0

Re: (ITS#5927) assertion error when using pcache
by hyc＠symas.com 07 Feb '09

07 Feb '09

ando(a)sys-net.it wrote: > mhardin(a)symas.com wrote: >> Sorry for the out-of-sequence reply. I'll test and let you know what I >> find. > > No problem. Note that if this is the cause of this issue, and, in any > case, if you have some "range" attributes in your response, you still > have an issue with those values. It seems that, in the spirit of > OpenLDAP software, we could be relatively liberal in accepting those > values provided we are able to consolidate them in a single entry with > no ranges. Apparently, what the proxies could do is: > > - whenever a range is obtained in a response > - iteratively query the server again for the same entry, > - requesting only that attribute for the next block of vals > - incrementally build the set of values > - return the consolidated entry > > This MUST be configurable, and documented as a nasty, expensive and > unnecessary hack. Even the thought of writing such an ugly hack is ... ugh... As an alternative, I suggest modifying slapd/ad.c to treat "=" the same as "-" in an option definition. Then simply adding attributeoption range= to slapd.conf will allow the values to be recognized. (With the constraint that '=' must be the final character in the option definition...) Let the client decide if they want to go thru the trouble of retrieving all the values or not. Certainly, for slapd to do it implicitly will overburden the (pathetically broken) AD server (otherwise they wouldn't need to break the value up into ranges in the first place). Indeed, doing this implicitly would amount to a DOS attack on the AD server. -- -- 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#5929) 'make test' uses installed libldap_r/liblber
by hyc＠symas.com 07 Feb '09

07 Feb '09

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: RedHat Linux x86_64 > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > "make test" uses installed instead of newly built libraries, > with ./configure --enable-dynamic LDFLAGS=<installed lib>. Don't do that. -- -- 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#5927) assertion error when using pcache
by mhardin＠symas.com 07 Feb '09

07 Feb '09

On Feb 7, 2009, at 9:21 AM, ando(a)sys-net.it wrote: > mhardin(a)symas.com wrote: >> Sorry for the out-of-sequence reply. I'll test and let you know >> what I >> find. > > No problem. Note that if this is the cause of this issue, and, in any > case, if you have some "range" attributes in your response, you still > have an issue with those values. Yes. I'm not sure what to do about them in the medium term. Not having slapd crash is a good first step, though :P > It seems that, in the spirit of > OpenLDAP software, we could be relatively liberal in accepting those > values provided we are able to consolidate them in a single entry with > no ranges. Apparently, what the proxies could do is: > > - whenever a range is obtained in a response > - iteratively query the server again for the same entry, > - requesting only that attribute for the next block of vals > - incrementally build the set of values > - return the consolidated entry > > This MUST be configurable, and documented as a nasty, expensive and > unnecessary hack. > I had thought it might be possible to craft this functionality as an overlay (we could call it "derange" :P), but I think you're right- it is more appropriate that it be something configurable in back-meta and back-ldap. This functionality is particularly interesting when one considers using Howard's nss_ov in conjunction with pcache and back- ldap communicating with directory servers that were never intended to handle the high loads that Unix/Linux name services can place on a directory server ;-) The high cost of the iterative searches might be mitigated through use of pcache. I'm thinking the searches to consolidate the ranged attributes would happen anyway, so better to do them in the proxy and cache the results than make each individual client have to do them. Cheers, -Matt > 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 > Fax: +39 0382 476497 > Email: ando(a)sys-net.it > ----------------------------------- > >

1 0

Re: (ITS#5927) assertion error when using pcache
by ando＠sys-net.it 07 Feb '09

07 Feb '09

mhardin(a)symas.com wrote: > Sorry for the out-of-sequence reply. I'll test and let you know what I > find. No problem. Note that if this is the cause of this issue, and, in any case, if you have some "range" attributes in your response, you still have an issue with those values. It seems that, in the spirit of OpenLDAP software, we could be relatively liberal in accepting those values provided we are able to consolidate them in a single entry with no ranges. Apparently, what the proxies could do is: - whenever a range is obtained in a response - iteratively query the server again for the same entry, - requesting only that attribute for the next block of vals - incrementally build the set of values - return the consolidated entry This MUST be configurable, and documented as a nasty, expensive and unnecessary hack. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5927) assertion error when using pcache
by mhardin＠symas.com 07 Feb '09

07 Feb '09

Sorry for the out-of-sequence reply. I'll test and let you know what I find. Cheers, -Matt On Feb 7, 2009, at 8:53 AM, mhardin(a)symas.com wrote: > On Feb 7, 2009, at 3:24 AM, Pierangelo Masarati wrote: > >> mhardin(a)symas.com wrote: >>> Some additional information: >>> Some objects being returned from AD have very large multi-valued >>> attributes (for example, member). AD is returning them in the >>> ";range" format, but they are not getting past back-meta. For >>> example, a direct search for the object in AD will return stuff >>> like this: >>> member;range=0-1499: CN=Alice Bar,OU=My-Company-Accounts,OU=User >>> Accounts,OU=Common,DC=my-company,DC=com >>> but doing the same search through slapd/back-meta using the same >>> credentials, the member attribute is not displayed at all. There >>> are no attribute maps in place that would cause this. >> >> If this is the cause, then back-meta should try to register the >> attribute name as a "proxied" attribute type, and slapd should be >> unable to correctly decode it because it contains a "=". Back-meta >> in the end should just ignore the whole attribute. >> > > Thanks, Pierangelo. That led me to ITS#5472 and several other postings > about the same issue. In particular: > >> [Petter Reinholdtsen said] >>> This notation is not handled by ldap_get_values(), and it return >>> NULL, resulting in a group with zero members. > >> [Kurt Zielenga replied] >> This is proper and well-intended behavior. You asked for values of >> returned under the attribute description "member", not the (invalid) >> attribute description "member;range=0-1499". Two attribute >> descriptions which share the same attribute type do not necessarily >> refer to the same attribute. > > This clearly explains the assertion pcache is reporting. Well-intended > behavior or not, there is a problem here because pcache takes down the > server whenever it encounters attribute values of this form. Given > Kurt's later comments about the provenance and ancestry of this > "standard", it seems to me the right thing for back-meta (and back- > ldap, for that matter) to do might be to just make the attribute > completely disappear. Appropriate messages output in debug mode or at > a particular log level might announce the fact that the attribute is > being disappeared. The pcache overlay, for its part, instead of > asserting, might instead log a warning and refuse to cache the object. > > Sound reasonable? > > -Matt > > >> 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 >> Fax: +39 0382 476497 >> Email: ando(a)sys-net.it >> ----------------------------------- >> > >

1 0

Re: (ITS#5927) assertion error when using pcache
by ando＠sys-net.it 07 Feb '09

07 Feb '09

mhardin(a)symas.com wrote: > This clearly explains the assertion pcache is reporting. Well-intended > behavior or not, there is a problem here because pcache takes down the > server whenever it encounters attribute values of this form. No longer :) > Given > Kurt's later comments about the provenance and ancestry of this > "standard", it seems to me the right thing for back-meta (and back- > ldap, for that matter) to do might be to just make the attribute > completely disappear. Appropriate messages output in debug mode or at > a particular log level might announce the fact that the attribute is > being disappeared. The pcache overlay, for its part, instead of > asserting, might instead log a warning and refuse to cache the object. > > Sound reasonable? See latest commit. If this fixes your problem, a message like conn=X op=Y meta_send_entry("cn=smtg"): slap_bv2undef_ad("member;range=Z-W"): ... Maybe you're not seeing it because slapd dies before logging? I could recreate the issue by entering slapd with gdb, let it get the attribute name, modify it by putting a "=" in between, and letting things go through. What happened is that slapd does not recognizes the attribute and continues the cycle. The subsequent attribute is not recognized as well because it is actually the first value! This should now be handled correctly. Please test. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5927) assertion error when using pcache
by mhardin＠symas.com 07 Feb '09

07 Feb '09

On Feb 7, 2009, at 3:24 AM, Pierangelo Masarati wrote: > mhardin(a)symas.com wrote: >> Some additional information: >> Some objects being returned from AD have very large multi-valued >> attributes (for example, member). AD is returning them in the >> ";range" format, but they are not getting past back-meta. For >> example, a direct search for the object in AD will return stuff >> like this: >> member;range=0-1499: CN=Alice Bar,OU=My-Company-Accounts,OU=User >> Accounts,OU=Common,DC=my-company,DC=com >> but doing the same search through slapd/back-meta using the same >> credentials, the member attribute is not displayed at all. There >> are no attribute maps in place that would cause this. > > If this is the cause, then back-meta should try to register the > attribute name as a "proxied" attribute type, and slapd should be > unable to correctly decode it because it contains a "=". Back-meta > in the end should just ignore the whole attribute. > Thanks, Pierangelo. That led me to ITS#5472 and several other postings about the same issue. In particular: > [Petter Reinholdtsen said] >> This notation is not handled by ldap_get_values(), and it return >> NULL, resulting in a group with zero members. > [Kurt Zielenga replied] > This is proper and well-intended behavior. You asked for values of > returned under the attribute description "member", not the (invalid) > attribute description "member;range=0-1499". Two attribute > descriptions which share the same attribute type do not necessarily > refer to the same attribute. This clearly explains the assertion pcache is reporting. Well-intended behavior or not, there is a problem here because pcache takes down the server whenever it encounters attribute values of this form. Given Kurt's later comments about the provenance and ancestry of this "standard", it seems to me the right thing for back-meta (and back- ldap, for that matter) to do might be to just make the attribute completely disappear. Appropriate messages output in debug mode or at a particular log level might announce the fact that the attribute is being disappeared. The pcache overlay, for its part, instead of asserting, might instead log a warning and refuse to cache the object. Sound reasonable? -Matt > 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 > Fax: +39 0382 476497 > Email: ando(a)sys-net.it > ----------------------------------- >

1 0

Re: (ITS#5927) assertion error when using pcache
by ando＠sys-net.it 07 Feb '09

07 Feb '09

mhardin(a)symas.com wrote: > Some additional information: > > Some objects being returned from AD have very large multi-valued > attributes (for example, member). AD is returning them in the ";range" > format, but they are not getting past back-meta. For example, a direct > search for the object in AD will return stuff like this: > > member;range=0-1499: CN=Alice Bar,OU=My-Company-Accounts,OU=User > Accounts,OU=Common,DC=my-company,DC=com > > but doing the same search through slapd/back-meta using the same > credentials, the member attribute is not displayed at all. There are > no attribute maps in place that would cause this. Apparently, that was it: back-meta (and back-ldap) was ignoring attribute names that cannot be parsed, but it was not discarding their values. Should be fixed now in HEAD. Please test. BTW, it seems that proxy backends could try to exploit this in order to intercept value ranges returned by AD and consolidate them in a single, LDAP compliant entry. Not something I'm too excited about, though. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5927) assertion error when using pcache
by ando＠sys-net.it 07 Feb '09

07 Feb '09

mhardin(a)symas.com wrote: > Some additional information: > > Some objects being returned from AD have very large multi-valued > attributes (for example, member). AD is returning them in the ";range" > format, but they are not getting past back-meta. For example, a direct > search for the object in AD will return stuff like this: > > member;range=0-1499: CN=Alice Bar,OU=My-Company-Accounts,OU=User > Accounts,OU=Common,DC=my-company,DC=com > > but doing the same search through slapd/back-meta using the same > credentials, the member attribute is not displayed at all. There are > no attribute maps in place that would cause this. If this is the cause, then back-meta should try to register the attribute name as a "proxied" attribute type, and slapd should be unable to correctly decode it because it contains a "=". Back-meta in the end should just ignore the whole attribute. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5929) 'make test' uses installed libldap_r/liblber
by h.b.furuseth＠usit.uio.no 06 Feb '09

06 Feb '09

Full_Name: Hallvard B Furuseth Version: HEAD OS: RedHat Linux x86_64 URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard "make test" uses installed instead of newly built libraries, with ./configure --enable-dynamic LDFLAGS=<installed lib>. It works if either --enable-dynamic or LDFLAGS is omitted. Minimal test: p=/site/ldap/install # ...or wherever OpenLDAP is installed ./configure --quiet --prefix=$p --enable-dynamic \ --disable-databases --disable-overlays --enable-ldap \ CPPFLAGS="-I$p/include" LDFLAGS="-L$p/lib -Wl,-rpath,$p/lib" make -s depend all Edit servers/slapd/slapd (a wrapper script from libtool): Insert echo "" ldd "$progdir/$program" | grep libl >&2 printenv | egrep '^(GCC|[A-Z_0-9]*PATH).*/' >&2 before exec "$progdir/$program" ${1+"$@"} cd tests ./run -b ldif test029-ldapglue Now "./run -b ldif test029-ldapglue" shows libldap_r-2-devel.so.0 => /site/ldap/install/lib/libldap_r-2-devel.so.0 liblber-2-devel.so.0 => /site/ldap/install/lib/liblber-2-devel.so.0 LD_LIBRARY_PATH=/usit/bombur/site/ldap/HEAD-commit/tests/../libraries:/usit/bombur/site/ldap/HEAD-commit/tests/../libraries: slapd#2 crashes unless the installed OpenLDAP is from February, otherwise testrun/slapd.2.log says symbol ldap_pvt_search is missing.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs