openldap-bugs September 2011

openldap-bugs@openldap.org

32 participants
59 discussions

Re: (ITS#7042) [PATCH] allow unsetting of tls_* options for syncrepl
by jvcelak＠redhat.com 12 Sep '11

12 Sep '11

On Monday 12 September 2011 19:00:08, Howard Chu wrote: > Thanks for passing along the report, but I'm not convinced this is a > legitimate issue. Servers that trust each other for replication should > accept each other's TLS certificates. As I see it, if their certs aren't > working in this configuration then their certificates were created with > the wrong usage flags, and this is not an OpenLDAP issue. You are definitely right. But disabling the options still might be useful for some people. Including the author of the patch. I think it is a very simple change which adds some extra bonus to current functionality. Nothing critical and no regressions are likely. It would be great, if you could include the patch even if you do not absolutely agree with disabling the client certificate authentication for replication. -- Jan Včelák Base Operating Systems Brno Red Hat Inc.

1 0

Re: (ITS#7042) [PATCH] allow unsetting of tls_* options for syncrepl
by hyc＠symas.com 12 Sep '11

12 Sep '11

jvcelak(a)redhat.com wrote: > Full_Name: Jan Vcelak > Version: master > OS: Linux > URL: ftp://ftp.openldap.org/incoming/jvcelak-20110912-syncrepl-allow-unsetting-o… > Submission from: (NULL) (209.132.186.34) > > > Hello, > > I'm just passing a patch submitted to our bugzilla: > https://bugzilla.redhat.com/show_bug.cgi?id=734187 > > To sum it up: If tls_cert/tls_key syncrepl options are not specified, server > setting is inherited and used. According to various reports on the Internet, > this is a feature, not a bug. Relying on hearsay "According to various reports on the Internet" is a stupid way to get information, particularly when it's already documented in the slapd.conf(5) and slapd-config(5) manpages. > However it forces a replica to use a client > certificate for authentication, because the tls_cert and tls_key options can not > be disabled. > > The patch allows tls_* options to be disabled, like this: "tls_cert=" > Without the patch, "file not found" error will occur. > The patch is written by the submitter of the bug report - Patrick Monnerat (pm > at datasphere dot ch). Thanks for passing along the report, but I'm not convinced this is a legitimate issue. Servers that trust each other for replication should accept each other's TLS certificates. As I see it, if their certs aren't working in this configuration then their certificates were created with the wrong usage flags, and this is not an OpenLDAP issue. -- -- 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#7042) [PATCH] allow unsetting of tls_* options for syncrepl
by jvcelak＠redhat.com 12 Sep '11

12 Sep '11

Full_Name: Jan Vcelak Version: master OS: Linux URL: ftp://ftp.openldap.org/incoming/jvcelak-20110912-syncrepl-allow-unsetting-o… Submission from: (NULL) (209.132.186.34) Hello, I'm just passing a patch submitted to our bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=734187 To sum it up: If tls_cert/tls_key syncrepl options are not specified, server setting is inherited and used. According to various reports on the Internet, this is a feature, not a bug. However it forces a replica to use a client certificate for authentication, because the tls_cert and tls_key options can not be disabled. The patch allows tls_* options to be disabled, like this: "tls_cert=" Without the patch, "file not found" error will occur. The patch is written by the submitter of the bug report - Patrick Monnerat (pm at datasphere dot ch). Jan

1 0

Re: (ITS#6925) [PATCH] Use inet_ntop for server when available
by masarati＠aero.polimi.it 08 Sep '11

08 Sep '11

>> Uploaded as xinli-its6925-110630.patch. > > Sorry, apparently I never received this message. It is not clear why you > conditioned it based on HAVE_GETADDRINFO; this seems to be repeated also > throughout the original code. > > The patch is not fine in slapd/daemon.c (the original code seems to be > broken as > well where inet_ntop(3) is already used), since peeraddr is set by > inet_ntop(3) > to point to the buffer addr[], and is used also when addr[] gets out of > scope > (#ifdef HAVE_TCPD). Fixing. The patch and the fixes are in git's master. In the commit log I forgot to mention that many of those fixes, significantly that for LDAP_CONNECTIONLESS, are blind. Please test and report. p.

1 0

Re: (ITS#6925) [PATCH] Use inet_ntop for server when available
by Pierangelo Masarati 08 Sep '11

08 Sep '11

> Uploaded as xinli-its6925-110630.patch. Sorry, apparently I never received this message. It is not clear why you conditioned it based on HAVE_GETADDRINFO; this seems to be repeated also throughout the original code. The patch is not fine in slapd/daemon.c (the original code seems to be broken as well where inet_ntop(3) is already used), since peeraddr is set by inet_ntop(3) to point to the buffer addr[], and is used also when addr[] gets out of scope (#ifdef HAVE_TCPD). Fixing. p.

1 0

Re: (ITS#7039) Use of uninitialized vars causes segfault when controls are parsed from LDIF
by masarati＠aero.polimi.it 08 Sep '11

08 Sep '11

Fixed in master

1 0

(ITS#7039) Use of uninitialized vars causes segfault when controls are parsed from LDIF
by masarati＠aero.polimi.it 08 Sep '11

08 Sep '11

Full_Name: Pierangelo Masarati Version: master, re24 OS: Linux on x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2.40.1.31) Submitted by: ando See <http://www.openldap.org/lists/openldap-technical/201109/msg00099.html>. p.

1 0

(ITS#7037) slapd crashes with syncrepl when replica cleared out DB
by ml+openldap＠esmtp.org 07 Sep '11

07 Sep '11

Full_Name: Claus Assmann Version: 2.4.26 OS: Red Hat Enterprise Linux Server release 5.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (63.211.143.38) While trying to determine how syncrepl behaves in various error conditions, I encountered a crash of slapd. A MASTER is set up to use push replication to a REPLICA as follows: database ldap hidden on suffix "" rootdn "cn=slapd-ldap" uri ldap://REPLICA/ lastmod on restrict all sync_use_subentry true acl-bind bindmethod=simple binddn="cn=Monitor" credentials=password syncrepl rid=001 provider=ldapi://%2Fvar%2Frun%2Fldapi binddn="cn=Manager" bindmethod=simple credentials=passwd searchbase="" type=refreshAndPersist retry="5 5 60 +" Reproduce: On REPLICA: stop slapd, clear out directory for DB, start slapd. On MASTER: add an entry master which has to be "synced" to REPLICA; run ldapsearch to lookup up that entry on MASTER slapd dumps core, backtrace: #0 0x00002b7e51344265 in raise () from /lib64/libc.so.6 #1 0x00002b7e51345d10 in abort () from /lib64/libc.so.6 #2 0x00002b7e5133d6e6 in __assert_fail () from /lib64/libc.so.6 #3 0x0000000000549546 in ldap_add_ext (ld=0xbba1bc0, dn=0x0, attrs=0xbeb7ed0, sctrls=0x0, cctrls=0x0, msgidp=0x435224c4) at add.c:126 #4 0x00000000004dbe6d in ldap_back_add (op=0x43523150, rs=0x43522770) at add.c:102 #5 0x0000000000481152 in overlay_op_walk (op=0x43523150, rs=0x43522770, which=op_add, oi=0xb9eb6c0, on=0x0) at backover.c:671 #6 0x00000000004816a7 in over_op_func (op=0x43523150, rs=0x43522770, which=op_add) at backover.c:723 #7 0x0000000000473706 in syncrepl_add_glue_ancestors (op=0x43523150, e=0x2b7e56628fb8) at syncrepl.c:3149 #8 0x000000000047384e in syncrepl_add_glue (op=0x43523150, e=0x2b7e56628fb8) at syncrepl.c:3193 #9 0x0000000000474795 in syncrepl_entry (si=0xb9eb1c0, op=0x43523150, entry=0x0, modlist=0x43523ca0, syncstate=<value optimized out>, syncUUID=<value optimized out>, syncCSN=0xbeb86e0) at syncrepl.c:2448 #10 0x000000000047c39b in do_syncrep2 (ctx=<value optimized out>, arg=<value optimized out>) at syncrepl.c:982 #11 do_syncrepl (ctx=<value optimized out>, arg=<value optimized out>) at syncrepl.c:1489 #12 0x000000000041eee3 in connection_read_thread (ctx=0x43523da0, argv=<value optimized out>) at connection.c:1276 #13 0x00000000005412dc in ldap_int_thread_pool_wrapper (xpool=0xb8fa1c0) at tpool.c:685 #14 0x00002b7e510ff73d in start_thread () from /lib64/libpthread.so.0 #15 0x00002b7e513e84bd in clone () from /lib64/libc.so.6 Note: this also happens with 2.4.23. On a VM instance, it causes a different error (see mail on list: "killed after 120 seconds")

1 0

Re: (ITS#7036) ldapsearch should attempt DNS-based fallback if possible
by seanius＠seanius.net 07 Sep '11

07 Sep '11

On Wed, Sep 07, 2011 at 12:51:10PM +0000, Pierangelo Masarati wrote: > As far as I understand from the code, libldap already behaves like that, i.e. it > loops through all the hosts returned by getaddrinfo(3). What's missing (in your > configuration of ldapsearch) is a network timeout parameter. Right now, you can > set it either using NETWORK_TIMEOUT in ldap.conf(5) or passing the command-line > switch -o nettimeout=<timeout>. I understand the latter is not documented in > ldapsearch(1), although it appears in the usage message of all tools. wonderful, confirmed that it works. so then yes, just a minor omission from the documentation :) sean

1 0

Re: (ITS#7036) ldapsearch should attempt DNS-based fallback if possible
by Pierangelo Masarati 07 Sep '11

07 Sep '11

As far as I understand from the code, libldap already behaves like that, i.e. it loops through all the hosts returned by getaddrinfo(3). What's missing (in your configuration of ldapsearch) is a network timeout parameter. Right now, you can set it either using NETWORK_TIMEOUT in ldap.conf(5) or passing the command-line switch -o nettimeout=<timeout>. I understand the latter is not documented in ldapsearch(1), although it appears in the usage message of all tools. As I'd consider this issue a software usage question rather than a bug (except for the missing documentation), I encourage you to continue discussion on the openldap-technical mailing list. p.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs September 2011