openldap-bugs February 2012

openldap-bugs@openldap.org

33 participants
146 discussions

(ITS#7158) Fix a crash in back-sql
by timo.teras＠iki.fi 08 Feb '12

08 Feb '12

Full_Name: Timo Teräs Version: 2.4.28 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.145.235.194) The back-sql crashes on startup with following backtrace: #0 0x0000045655d11efc in config_generic_wrapper () #1 0x0000045655d1187e in read_config_file () #2 0x0000045655d08fb6 in read_config () #3 0x0000045655cffc15 in main () This is because the be_cf_ocs is not initialized properly.

1 0

Re: (ITS#7157) UTF-8 support for "mail" attribute
by quanah＠zimbra.com 07 Feb '12

07 Feb '12

--On Tuesday, February 07, 2012 9:03 PM +0000 alfiej(a)opera.com wrote: > Full_Name: Alfie John > Version: 2.4.23 > OS: Debian Squeeze > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (220.245.36.226) > > > When searching for Chinese names in the "to:" field under Thunderbird, I > see asserted_value_validate_normalize() not returning LDAP_SUCCESS in > filter.c. This is because the "mail" attribute in core.schema is of type > "IA5 String" but the Chinese name falls outside the character set. > > The work around I have is to modify the "mail" attributetype in the > core.schema from: > > attributetype ( 0.9.2342.19200300.100.1.3 > NAME ( 'mail' 'rfc822Mailbox' ) > DESC 'RFC1274: RFC822 Mailbox' > EQUALITY caseIgnoreIA5Match > SUBSTR caseIgnoreIA5SubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} ) > > to: > > attributetype ( 0.9.2342.19200300.100.1.3 > NAME ( 'mail' 'rfc822Mailbox' ) > DESC 'RFC1274: RFC822 Mailbox' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) > > Dieter Kl?nter pointed out on the openldap-technical mailing list that > this breaks RFC-5322. However Charles T. Brooks suggests: > > Non-english character sets are going to become part of > hostnames and DNS. That's inevitable. > > Mail addresses are based on DNS hostnames. > > Ergo, mail attributes will one day need to support all possible > characters. > > Given that, I think the above changes to core.schema seem worthwhile. I would say then, that the proper place to bring this up would be with the IETF. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7157) UTF-8 support for "mail" attribute
by alfiej＠opera.com 07 Feb '12

07 Feb '12

Full_Name: Alfie John Version: 2.4.23 OS: Debian Squeeze URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (220.245.36.226) When searching for Chinese names in the "to:" field under Thunderbird, I see asserted_value_validate_normalize() not returning LDAP_SUCCESS in filter.c. This is because the "mail" attribute in core.schema is of type "IA5 String" but the Chinese name falls outside the character set. The work around I have is to modify the "mail" attributetype in the core.schema from: attributetype ( 0.9.2342.19200300.100.1.3 NAME ( 'mail' 'rfc822Mailbox' ) DESC 'RFC1274: RFC822 Mailbox' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} ) to: attributetype ( 0.9.2342.19200300.100.1.3 NAME ( 'mail' 'rfc822Mailbox' ) DESC 'RFC1274: RFC822 Mailbox' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) Dieter Klünter pointed out on the openldap-technical mailing list that this breaks RFC-5322. However Charles T. Brooks suggests: Non-english character sets are going to become part of hostnames and DNS. That's inevitable. Mail addresses are based on DNS hostnames. Ergo, mail attributes will one day need to support all possible characters. Given that, I think the above changes to core.schema seem worthwhile.

1 0

Re: (ITS#7156) definement missing in ldapsearch.c
by h.b.furuseth＠usit.uio.no 07 Feb '12

07 Feb '12

On Tue, 7 Feb 2012 12:19:04 GMT, Kick.Tobias(a)web.de wrote: > It seems that in ldapsearch.c a ifdef-statement for HAVE_SYS_TIME_H > is missing like this: > > #ifdef HAVE_SYS_TIME_H > #include <sys/time.h> > #endif Fixed in master: Added #include <ac/time.h> which does the above. Please test. -- Hallvard

1 0

Re: (ITS#7153) OpenLDAP doesn't start after some configuration modifications
by michael＠stroeder.com 07 Feb '12

07 Feb '12

Raphaël Ouazana-Sustowski wrote: > On Tue, 07 Feb 2012 14:36:22 +0100, Michael Ströder wrote: >> Raphaël Ouazana-Sustowski wrote: >>> Wouldn't it be possible to have a more generic solution, eg: while each >>> configuration change, OpenLDAP tests that configuration is still valid. >> >> While checking the configuration data itself seems feasible it does >> not scale well to check all entries whether they still contain a >> certain schema element. > > Again I was talking about a more generic case. ??? > For the specific case of schema modification, I don't think that OpenLDAP > doesn't start if some entries are missing some schema elements. Schema and all entries have to be consistent. Periodically checking with slapschema whether everything's still alright is a good idea. > My point is only that OpenLDAP should not bring the administrator to > a situation where he cannot restart the service. Nothing prevents an admin to do rm -rf /var/openldap/databases so to some degree an admin has to know what he does. Ciao, Michael.

1 0

Re: (ITS#7153) OpenLDAP doesn't start after some configuration modifications
by michael＠stroeder.com 07 Feb '12

07 Feb '12

Raphaël Ouazana-Sustowski wrote: > Wouldn't it be possible to have a more generic solution, eg: while each > configuration change, OpenLDAP tests that configuration is still valid. While checking the configuration data itself seems feasible it does not scale well to check all entries whether they still contain a certain schema element. Also if you use slapo-accesslog and it contains removed attributes in attributes redMod or reqOld you cannot fully restore the accesslog DB with slapadd. So using OBSOLETE is best practice. Experimental things you do in your test environment without asking for support is completely up to you. Ciao, Michael.

1 0

Re: (ITS#7153) OpenLDAP doesn't start after some configuration modifications
by michael＠stroeder.com 07 Feb '12

07 Feb '12

raphael.ouazana(a)linagora.com wrote: > This is a little bit like shooting himself in the foot: > a/ Create a new attribute with back-config > b/ Create a second new attribute which inherits from the first one with > back-config > c/ Remove the first attribute with back-config > d/ OpenLDAP does not complain. But when you restart the server, you get an error > message. It boils down to that back-config should not allow to remove schema elements which are somewhere used. In this context "used" means 1. referenced in another schema element or 2. used in an entry in one of the database backends. While 1. could be easily checked by slapd thinking about 2. leads to the conclusion that schema elements should not be removable at all. There's a possibility to mark schema elements as OBSOLETE. This is what I consider best practice. Also it still keeps the old OID reserved. (My web2ldap displays OBSOLETE schema elements as struck out in the schema viewer so one can easily notice whether there are OBSOLETE attribute types referenced e.g. in an active object class.) Ciao, Michael.

1 0

(ITS#7156) definement missing in ldapsearch.c
by Kick.Tobias＠web.de 07 Feb '12

07 Feb '12

Full_Name: Tobias Kick Version: 2.4.28 OS: MinGW URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (94.16.0.17) When configured in portable.h #define HAVE_SYS_TIME_H 1 the compiler brings the error: make[2]: Entering directory `/mingw64/tmp/openldap-2.4.28/clients/tools' ../../build/mkversion -v "2.4.28" -s ldapsearch > ldsversion.c gcc -g -O2 -I../../include -I../../include -c -o ldapsearch.o ldapsearch.c ldapsearch.c: In function 'dosearch': ldapsearch.c:1379:17: error: storage size of 'tv' isn't known ldapsearch.c:1380:17: error: storage size of 'tv_timelimit' isn't known make[2]: *** [ldapsearch.o] Error 1 make[2]: Leaving directory `/mingw64/tmp/openldap-2.4.28/clients/tools' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/mingw64/tmp/openldap-2.4.28/clients' make: *** [all-common] Error 1 It seems that in ldapsearch.c a ifdef-statement for HAVE_SYS_TIME_H is missing like this: #ifdef HAVE_SYS_TIME_H #include <sys/time.h> #endif

1 0

(ITS#7153) OpenLDAP doesn't start after some configuration modifications
by raphael.ouazana＠linagora.com 07 Feb '12

07 Feb '12

Full_Name: Raphael Ouazana Version: 2.4.26 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.173.78.196) Hi, This is a little bit like shooting himself in the foot: a/ Create a new attribute with back-config b/ Create a second new attribute which inherits from the first one with back-config c/ Remove the first attribute with back-config d/ OpenLDAP does not complain. But when you restart the server, you get an error message. More problematically, you cannot modify the configuration anymore, because slapcating the configuration to edit it gives you the same error message: $ sbin/slapcat -F etc/openldap/slapd.d -n0 olcAttributeTypes: value #0 olcAttributeTypes: AttributeType not found: "xxx" config error processing cn={22}yyy,cn=schema,cn=config: olcAttributeTypes: AttributeType not found: "xxx" slapcat: bad configuration directory!

1 0

RE : (ITS#7149) Back-perl, Back-shell and Binary Data
by jiashun.qian＠atos.net 06 Feb '12

06 Feb '12

Now the new patch encode the binary data to base64 by using slap_ad_is_binary to check if it's binary data, and using lutil_b64_ntop for the encode. *** ../openldap-2.4.28.org/servers/slapd/back-perl/modify.c 2011-11-25 19:52:29.000000000 +0100 --- servers/slapd/back-perl/modify.c 2012-02-06 17:41:44.638861010 +0100 *************** *** 16,21 **** --- 16,22 ---- */ #include "perl_back.h" + #include "lutil.h" int perl_back_modify( *************** *** 26,31 **** --- 27,33 ---- Modifications *modlist = op->orm_modlist; int count; int i; + struct berval b64_data; PERL_SET_CONTEXT( PERL_INTERPRETER ); ldap_pvt_thread_mutex_lock( &perl_interpreter_mutex ); *************** *** 61,67 **** mods->sm_values != NULL && mods->sm_values[i].bv_val != NULL; i++ ) { ! XPUSHs(sv_2mortal(newSVpv( mods->sm_values[i].bv_val, 0 ))); } /* Fix delete attrib without value. */ --- 63,80 ---- mods->sm_values != NULL && mods->sm_values[i].bv_val != NULL; i++ ) { ! if ( slap_ad_is_binary(mods->sm_desc) ) { ! b64_data.bv_len = LUTIL_BASE64_ENCODE_LEN(mods->sm_values[i].bv_len) + 1; ! b64_data.bv_val = ber_memalloc( b64_data.bv_len + 1 ); ! b64_data.bv_len = lutil_b64_ntop( ! (unsigned char *) mods->sm_values[i].bv_val, ! mods->sm_values[i].bv_len, ! b64_data.bv_val, b64_data.bv_len ); ! XPUSHs(sv_2mortal(newSVpv( b64_data.bv_val, 0 ))); ! ber_memfree( b64_data.bv_val ); ! } else { ! XPUSHs(sv_2mortal(newSVpv( mods->sm_values[i].bv_val, 0 ))); ! } } /* Fix delete attrib without value. */ *** ../openldap-2.4.28.org/servers/slapd/back-shell/modify.c 2011-11-25 19:52:29.000000000 +0100 --- servers/slapd/back-shell/modify.c 2012-02-06 17:40:14.861837487 +0100 *************** *** 37,42 **** --- 37,43 ---- #include "slap.h" #include "shell.h" + #include "lutil.h" int shell_back_modify( *************** *** 50,55 **** --- 51,57 ---- Entry e; FILE *rfp, *wfp; int i; + struct berval b64_data; if ( si->si_modify == NULL ) { send_ldap_error( op, rs, LDAP_UNWILLING_TO_PERFORM, *************** *** 105,112 **** if( mod->sm_values != NULL ) { for ( i = 0; mod->sm_values[i].bv_val != NULL; i++ ) { ! fprintf( wfp, "%s: %s\n", mod->sm_desc->ad_cname.bv_val, ! mod->sm_values[i].bv_val /* binary! */ ); } } --- 107,126 ---- if( mod->sm_values != NULL ) { for ( i = 0; mod->sm_values[i].bv_val != NULL; i++ ) { ! if ( slap_ad_is_binary(mod->sm_desc) ) { ! b64_data.bv_len = LUTIL_BASE64_ENCODE_LEN(mod->sm_values[i].bv_len) + 1; ! b64_data.bv_val = ber_memalloc( b64_data.bv_len + 1 ); ! b64_data.bv_len = lutil_b64_ntop( ! (unsigned char *) mod->sm_values[i].bv_val, ! mod->sm_values[i].bv_len, ! b64_data.bv_val, b64_data.bv_len ); ! fprintf( wfp, "%s: %s\n", mod->sm_desc->ad_cname.bv_val, ! b64_data.bv_val ); ! ber_memfree( b64_data.bv_val ); ! } else { ! fprintf( wfp, "%s: %s\n", mod->sm_desc->ad_cname.bv_val, ! mod->sm_values[i].bv_val ); ! } } } ________________________________________ De : openldap-bugs-bounces(a)OpenLDAP.org [openldap-bugs-bounces(a)OpenLDAP.org] de la part de hyc(a)symas.com [hyc(a)symas.com] Date d'envoi : jeudi 2 février 2012 21:44 À : openldap-its(a)openldap.org Objet : Re: (ITS#7149) Back-perl, Back-shell and Binary Data llg(a)portaildulibre.fr wrote: > Le 02/02/2012 20:32, hyc(a)symas.com a écrit : >> jiashun.qian(a)atos.net wrote: >>> Full_Name: Jiashun QIAN >>> Version: 2.4.28 >>> OS: CentOS 6 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (85.115.60.180) >>> >>> >>> The backend shell and the backend perl can't handle some binary data. >>> >>> This occurs only with MODIFY because when ADD the binary data is encoded in >>> base64 but not MODIFY. >>> >>> The binary data is truncated when if it contains \0. In fact, data is stored in >>> a linked list of char * and treated as characters. >>> >>> --- >>> servers/slapd/back-perl/modify.c >>> XPUSHs(sv_2mortal(newSVpv( mods->sm_values[i].bv_val, 0 ))); >>> --- >>> >>> The type of mods->sm_values[i].bv_val is char*. >>> >>> To handle the binary data, for back-perl, just change another function mXPUSHp, >>> which we can put the exacte length of mod->sm_values[i].bv_val as parameter, >>> it's mod->sm_values[i].bv_len. So it will push the total data. >> That is obviously the wrong approach. Since these backends communicate using >> LDIF, binary values should be base64 encoded according to the LDIF rules. > The input LDIF file for ldap_modify contains base64 encoded > usercertificate, but back-perl receives binary data. > This behaviour only occured with modification action : with add action, > certificate is received base64 encoded. Yes, I already understood that. You're still not understanding what I said. Your patch should do the appropriate checks for binary data and do the proper base64 encoding for the modify values that back-perl (or back-shell) sends to the perl module (or shell script). This has nothing to do with the input LDIF file, this is about how slapd transmits internal data from a backend to the external perl or shell scripts. >> Thanks for the patch, but we can't merge it since the provided solution is wrong. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ ________________________________ Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité du groupe Atos ne pourra être engagée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être engagée pour tout dommage résultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos group liability cannot be triggered for the message content. Although the sender endeavors to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.

1 0

← Newer
1
...
8
9
10
11
12
13
14
15
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs February 2012