openldap-bugs August 2008

openldap-bugs@openldap.org

40 participants
169 discussions

Re: (ITS#5655) add option for setting minimum TLS/SSL protocol
by michael＠stroeder.com 13 Aug '08

13 Aug '08

guenther+ldapdev(a)sendmail.com wrote: > It's time for SSL version 2.0 to die: Yupp! > As a first step, here's a patch against the CVS trunk that adds the ability to > set the minimum TLS/SSL protocol from the C API (LDAP_OPT_X_TLS_PROTOCOL_MIN), > the ldap.conf (TLS_PROTOCOL_MIN), and the slapd config > (TLSProtocolMin/olcTLSProtocolMin). Possible settings are: > C API ldap_[sg]et_option() ldap.conf/slapd config > ----------------------------------------------------------- > LDAP_OPT_X_TLS_PROTOCOL_SSLv2 SSLv2 > LDAP_OPT_X_TLS_PROTOCOL_SSLv3 SSLv3 > LDAP_OPT_X_TLS_PROTOCOL_TLSv1_0 TLSv1 OR TLSv1.0 From my understanding this is what LDAP_OPT_X_TLS_CIPHER_SUITE is for, isn't it? It's directly passed to OpenSSL and can also be used to enable or disable SSLv2, SSLv3 and TLSv1 besides choosing the ciphers itself. Apache HTTP server does it also that way. See: http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslciphersuite This patch could be necessary if different SSL implementations can be used which have different parameters for this. Still you would have to set other implementation-specific parameters... Ciao, Michael.

1 0

Re: (ITS#5655) add option for setting minimum TLS/SSL protocol
by hyc＠symas.com 13 Aug '08

13 Aug '08

guenther+ldapdev(a)sendmail.com wrote: > Full_Name: Philip Guenther > Version: > OS: Linux > URL: ftp://ftp.openldap.org/incoming/guenther-080813.patch > Submission from: (NULL) (64.58.1.252) > > > It's time for SSL version 2.0 to die: it has numerous weaknesses and has been > superseded by SSL version 3.0 and TLS version 1.0 for *years*. Indeed, the LDAP > Start_Tls extended operation is defined by reference to the TLS standard. > > (It could be argued that a client that sends an SSLv2-compatible handshake after > doing Start_Tls is non-compliant, or at least non-interoperable, as servers are > only required to support true TLS handshakes.) > > As a first step, here's a patch against the CVS trunk that adds the ability to > set the minimum TLS/SSL protocol from the C API (LDAP_OPT_X_TLS_PROTOCOL_MIN), > the ldap.conf (TLS_PROTOCOL_MIN), and the slapd config > (TLSProtocolMin/olcTLSProtocolMin). Possible settings are: > C API ldap_[sg]et_option() ldap.conf/slapd config > ----------------------------------------------------------- > LDAP_OPT_X_TLS_PROTOCOL_SSLv2 SSLv2 > LDAP_OPT_X_TLS_PROTOCOL_SSLv3 SSLv3 > LDAP_OPT_X_TLS_PROTOCOL_TLSv1_0 TLSv1 OR TLSv1.0 Using an option flag for each protocol version seems excessive; it will be a recurring maintenance burden because each new option flag reflects an API change. (GnuTLS claims to already support TLSv1.2.) This should use a single option flag and a numeric or bitfield argument for selecting protocols instead. Since we're talking about minimum settings, it should likely just be an increasing range of numbers. I note that the on-the-wire protocol version is just a 16 bit integer; we could define protocol names that correspond directly to these values. > (1.0, because TLSv1.1 is already published, even though OpenSSL doesn't support > it yet) -- -- 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#5655) add option for setting minimum TLS/SSL protocol
by guenther+ldapdev＠sendmail.com 13 Aug '08

13 Aug '08

Full_Name: Philip Guenther Version: OS: Linux URL: ftp://ftp.openldap.org/incoming/guenther-080813.patch Submission from: (NULL) (64.58.1.252) It's time for SSL version 2.0 to die: it has numerous weaknesses and has been superseded by SSL version 3.0 and TLS version 1.0 for *years*. Indeed, the LDAP Start_Tls extended operation is defined by reference to the TLS standard. (It could be argued that a client that sends an SSLv2-compatible handshake after doing Start_Tls is non-compliant, or at least non-interoperable, as servers are only required to support true TLS handshakes.) As a first step, here's a patch against the CVS trunk that adds the ability to set the minimum TLS/SSL protocol from the C API (LDAP_OPT_X_TLS_PROTOCOL_MIN), the ldap.conf (TLS_PROTOCOL_MIN), and the slapd config (TLSProtocolMin/olcTLSProtocolMin). Possible settings are: C API ldap_[sg]et_option() ldap.conf/slapd config ----------------------------------------------------------- LDAP_OPT_X_TLS_PROTOCOL_SSLv2 SSLv2 LDAP_OPT_X_TLS_PROTOCOL_SSLv3 SSLv3 LDAP_OPT_X_TLS_PROTOCOL_TLSv1_0 TLSv1 OR TLSv1.0 (1.0, because TLSv1.1 is already published, even though OpenSSL doesn't support it yet) This option is set up to specify a minimum version instead of permitting arbitrary control of which versions are supported because the SSL/TLS version negotiation assumes that both ends support a contiguous range. If one end has a gap in what it supports (e.g., SSLv2 and TLSv1, but not SSLv3), then it'll fail to handshake with another one that has the missing version as its highest supported version, even though they both support a lower version. Simply setting just the lower-bound prevents the specification of such a 'silly-state'. (for example: "openssl s_client -no_ssl3" will fail to handshake with "openssl s_server -no_tls1", even though they both support SSLv2. Ditto if you flip the ends.)

1 0

Re: (ITS#5640) slapd scans too many objects at startup
by ghenry＠suretecsystems.com 13 Aug '08

13 Aug '08

ali.pouya(a)free.fr wrote: > Full_Name: Ali Pouya > Version: 2.4.11 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (145.242.11.4) > > > I have a test directory with two mirrors A and B and a replica C connected to > A. > I usaually use server A for write operations. > > I encounter the following problems : > > > 1) If the data base is initiated in stand alone (so serverID defaults to zero) > and then I set serverIDs 1 and 2 for A and B then each time I start up slapd on > C it scans all of the objects writtent on A afterwards, producing the followin > log for each object : Why do you change serverID? > > ====================================================== > entry_decode: "cn=testr1,ou=resources,ou=mefi,o=gouv,c=fr" > <= entry_decode(cn=testr1,ou=resources,ou=mefi,o=gouv,c=fr) > => bdb_dn2id("cn=testr1,ou=resources,ou=mefi,o=gouv,c=fr") > <= bdb_dn2id: got id=0x9 > => test_filter > GE > => access_allowed: search access to "cn=testr1,ou=resources,ou=mefi,o=gouv,c=fr" > "entryCSN" requested > <= root access granted > => access_allowed: search access granted by manage(=mwrscxd) > <= test_filter 6 > ====================================================== > > For a directory with 10 million objects the this takes more than one hour (slapd > is running but the service is not available). > If I set serverID=3 on the replica C the problem disapears. So you're saying serverID=0, serverID=1, serverID=2 makes a difference from serverID=1, serverID=2, serverID=3? They only have to be unique. > > 2) If I do only one write operation on B, then I get two contextCSN values, > which is normal. > > But il this case slapd on B scans, at each startup, all objecs written on A > after the write operation on B. > The log and the effect are similar to those explained above. > > Should I consider this as a normal behaviour or a bug ? There are no writes above, you've only shown searches. How many times do you restart slapd and why? > > My mirror configuration is similar to the one recommended in Admin's Guide. > Of course I can provide more detailed information if required. > > Thanks for your HELP > Best Regards > Ali > > -- Kind Regards, Gavin Henry. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

1 0

(ITS#5654) memberof syntax clunky
by abartlet＠samba.org 11 Aug '08

11 Aug '08

Full_Name: Andrew Bartlett Version: CVS HEAD OS: Fedora 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (124.176.63.104) As instructed by Howard: From: Howard Chu <hyc(a)highlandsun.com> To: samba-technical(a)lists.samba.org Subject: Re: samba4-ol-mmr Date: Mon, 11 Aug 2008 21:09:52 -0700 (Tue, 14:09 EST) > # Generated from schema in /usr/local/samba/private/ldap/schema-tmp.ldb > overlay memberof > memberof-dn cn=samba-admin,cn=samba > memberof-dangling error > memberof-refint TRUE > memberof-group-oc top > memberof-member-ad msDS-ObjectReference > memberof-memberof-ad msDS-ObjectReferenceBL > memberof-dangling-error 32 (repeats once per attribute link) ... Mmm, that's really clunky. Someone should file an OpenLDAP enhancement request on the memberof config syntax. You should only need to instantiate the overlay once, and then it should just take a list of oc/forward-ad/back-ad config options. > Look closely at how we sub in memberof configuration into the > slapd.conf. I suggest that you could add a ${REPL_CONFIG} after each > database, which the script could sub with either "" or by reading and > subing in a slapd-replica.conf -- -- 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#5641) Segmentation fault - slaptest and slapd
by hfranzke＠tee.toshiba.de 11 Aug '08

11 Aug '08

Tested and it works. Thanks. Helmut Franzke On Saturday 09 August 2008 10:30:35 Pierangelo Masarati wrote: > 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 > ----------------------------------- -- Toshiba Electronics Europe GmbH Helmut Franzke E-Mail: hfranzke(a)tee.toshiba.de Tel: +49-211-5296-666 Fax: +49-211-5296-386 ----------------- () Join the ASCII ribbon campaign against html email /\ and Microsoft attachments. CONFIDENTIALITY DISCLAIMER The information in this email and in any attachments is confidential and may be privileged. If you are not the intended recipient, please destroy this message, delete any copies held on your systems and notify the sender immediately. You should not retain, copy or use this email for any purpose outside of any NDA currently existing between Toshiba Electronics Europe GmbH and yourselves. Toshiba Electronics Europe GmbH Hansaallee 181 - 40549 Duesseldorf - Germany Phone: +49 (211) 5296-0 - Fax: +49 (211) 5296-400 Handelsregister Duesseldorf HRB 22487 Geschaeftsfuehrer: Hitoshi Otsuka Amtsgericht Duesseldorf

1 0

(ITS#5653) Segmentation Fault running slapd with mysql back-end
by ollieeillo＠yahoo.co.uk 11 Aug '08

11 Aug '08

Full_Name: Ollie Version: openldap-2.3.39 OS: CentOS release 4.5 (Final) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.248.134.226) CentOS release 4.5 (Final) openldap-2.3.39 (Stable) mysql 5.0.27-max (Cluster) localhost openssl-0.9.8h libiodbc-3.52.6 (iODBC) slapd.conf ###################### include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema pidfile /usr/local/var/run/slapd.pid argsfile /usr/local/var/run/slapd.args allow bind_v2 access to * by * read access to * by * write database sql dbname openldap dbuser ldap dbpasswd <snip> loglevel 264 suffix "dc=example,dc=com" rootdn "cn=Manager,dc=example,dc=com" ################################################# Worked perfectly with db-4.5.20 but as soon as mysql is used a segmentation fault happens. Strangely, if the mysql database tables are unpopulated then slapd starts fine. It's only once the test tables are populated that segmentation fault happens mysql openldap < testdb_data.sql mysql openldap < testdb_metadata.sql iodbc ####################### ./configure --with-iodbc-inidir=/etc make make install running slapd ####################### # /usr/local/libexec/slapd -d -1 .... backsql_db_open(): setting "DELETE FROM ldap_entry_objclasses WHERE entry_id=?" by default ==>backsql_get_db_conn() ==>backsql_open_db_conn(18446744073709551615) <==backsql_open_db_conn(18446744073709551615) backsql_open_db_conn(18446744073709551615): connected, adding to tree. <==backsql_get_db_conn() ==>backsql_load_schema_map() backsql_load_schema_map(): oc_query "SELECT id,name,keytbl,keycol,create_proc,delete_proc,expect_return FROM ldap_oc_mappings" backsql_load_schema_map(): objectClass "organization": keytbl="institutes" keycol="id" expect_return: add=0, del=0; attributes: backsql_load_schema_map(): objectClass "inetOrgPerson": keytbl="persons" keycol="id" expect_return: add=0, del=0; attributes: backsql_load_schema_map(): objectClass "document": keytbl="documents" keycol="id" expect_return: add=0, del=0; attributes: backsql_load_schema_map(): objectClass "referral": keytbl="referrals" keycol="id" expect_return: add=0, del=0; attributes: backsql_load_schema_map(): at_query "SELECT name,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return,sel_expr_u FROM ldap_attr_mappings WHERE oc_map_id=?" backsql_oc_get_attr_mapping(): executing at_query "SELECT name,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return,sel_expr_u FROM ldap_attr_mappings WHERE oc_map_id=?" for objectClass "document" with param oc_id="2" attributeType: name="(null)" sel_expr="(null)" from="(null)" join_where="(null)" add_proc="(null)" delete_proc="(null)" sel_expr_u="" Segmentation fault ############################################ >>>>> Executing all LDAP tests for sql >>>>> Starting sql-test000-read ... running defines.sh Starting slapd on TCP/IP port 9011... Testing SQL backend read operations... Waiting 5 seconds for slapd to start... ./scripts/sql-test000-read: line 42: 3729 Segmentation fault $SLAPD -f $CONF1 -h $URI1 -d $LVL $TIMING >$LOG1 2>&1 Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... make: *** [sql-yes] Interrupt

1 0

(ITS#5652) configure errors
by edpena＠cisco.com 09 Aug '08

09 Aug '08

Full_Name: Ed Pena Version: openldap-2.3.39 OS: hpux 11.11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (64.102.254.33) checking arpa/nameser.h usability... no checking arpa/nameser.h presence... yes configure: WARNING: arpa/nameser.h: present but cannot be compiled configure: WARNING: arpa/nameser.h: check for missing prerequisite headers? configure: WARNING: arpa/nameser.h: see the Autoconf documentation configure: WARNING: arpa/nameser.h: section "Present But Cannot Be Compiled" configure: WARNING: arpa/nameser.h: proceeding with the preprocessor's result configure: WARNING: arpa/nameser.h: in the future, the compiler will take precedence configure: WARNING: ## --------------------------------------------- ## configure: WARNING: ## Report this to <http://www.openldap.org/its/> ## configure: WARNING: ## --------------------------------------------- ## checking shadow.h usability... no checking shadow.h presence... yes configure: WARNING: shadow.h: present but cannot be compiled configure: WARNING: shadow.h: check for missing prerequisite headers? configure: WARNING: shadow.h: see the Autoconf documentation configure: WARNING: shadow.h: section "Present But Cannot Be Compiled" configure: WARNING: shadow.h: proceeding with the preprocessor's result configure: WARNING: shadow.h: in the future, the compiler will take precedence configure: WARNING: ## --------------------------------------------- ## configure: WARNING: ## Report this to <http://www.openldap.org/its/> ## configure: WARNING: ## --------------------------------------------- ## checking for shadow.h... yes

1 0

(ITS#5651) pthread error in configure
by edpena＠cisco.com 09 Aug '08

09 Aug '08

Full_Name: Ed Pena Version: openldap-2.3.39 OS: hpux 11.11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (64.102.254.33) checking pthread.h usability... no checking pthread.h presence... yes configure: WARNING: pthread.h: present but cannot be compiled configure: WARNING: pthread.h: check for missing prerequisite headers? configure: WARNING: pthread.h: see the Autoconf documentation configure: WARNING: pthread.h: section "Present But Cannot Be Compiled" configure: WARNING: pthread.h: proceeding with the preprocessor's result configure: WARNING: pthread.h: in the future, the compiler will take precedence configure: WARNING: ## --------------------------------------------- ## configure: WARNING: ## Report this to <http://www.openldap.org/its/> ## configure: WARNING: ## --------------------------------------------- ## checking for pthread.h... yes

1 0

Re: (ITS#5628) dereferencing user with translucent overlay
by hyc＠symas.com 09 Aug '08

09 Aug '08

Pierangelo Masarati wrote: > hyc(a)symas.com wrote: > >> Seems that we should add a backend_attribute handler to the translucent overlay. > > That's not going to work anyway, since the overlay's bi_acl_attribute > method is not going to be called anyway. In fact, any call to > backend_attribute will be cast into a call to bi_entry_get_rw, so only > by implementing translucent_entry_get_rw we could have a chance to look > the remote entry up. But then we'd probably have issues in the > subsequent call to translucent_entry_release, to distinguish whether the > looked-up entry was from the local or the remote database... And see > ITS#5650: right now, even if the attribute is not local, the local entry > will always be returned. I think in most cases the entry that translucent returns will have to be constructed from both local and remote anyway. In which case, translucent_release should just be a call to entry_free; the original local entry should be duplicated and released immediately. >>>> I've also tried to hack the translucent overlay so that it would support the >>>> bi_entry_get_rw callback but I haven't been able to provide something that would >>>> even satisfy me. I suppose I would have to use some sort of callback mechanism >>>> like translucent_search_cb but I haven't figured it out yet. >>> That's another problem I ran through when trying to add rewrite >>> capabilities to the slapo-rwm(5) overlay, so that authorization could be >>> rewrapped when performed through virtual data views. However, I believe >>> the API of bi_entry_get_rw be modified for overlays, since the current >>> API does not allow calls to modify their arguments. I'd leave that >>> alone by now. >> Haven't looked closely at this yet... -- -- 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

← Newer
1
...
7
8
9
10
11
12
13
...
17
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 August 2008