openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Re: (ITS#6610) Client receives SIGPIPE when connected via ldapi with TLS
by hyc＠symas.com 29 Jul '10

29 Jul '10

jzeleny(a)redhat.com wrote: > Full_Name: Jan Zeleny > Version: 2.4.23 > OS: Linux > URL: http://jzeleny.fedorapeople.org/debug/openldap/sigpipe-traces.tar.bz2 > Submission from: (NULL) (209.132.186.34) > > > When running slapd listening on local socket (ldapi:///), clients connecting to > it will sometimes SIGPIPE when using TLS. This happens in about 70% times. > > How to reproduce: > generate a pem certificate > slapd -h ldapi:/// > ldapsearch -H ldapi:/// -ZZ -x -d -1 > > I'm attaching straces from both slapd and ldapsearch. What seems to be happening > is that slapd receives EAGAIN during the read from socket, marks it for another > read, but then terminates a reading thread and closes the connection, while > client still wants to write some data. When doing ldapsearch, it does this after > result was returned, that's why it can be seen probably only in debugging mode. > > The issue was originally reported on 2.3.43, but I successfully reproduced it on > newer versions, including 2.4.23. The only exception was Fedora rawhide version > (currently 2.4.22), which is built with NSS instead of OpenSSL. NSS (and NSPR) > doesn't seem to support local sockets at all, so it is not possible to use ldapi > with -ZZ any more. Not sure this is worth investigating, since there's no reason to use TLS on ldapi://, and as you already said, it won't even be possible with the upcoming (rawhide) packages. > I'm attaching straces from both successful and unsuccessful run. For complete > information here is URL of relevant redhat bugzilla: > https://bugzilla.redhat.com/show_bug.cgi?id=564108 In regards to the original report, just leave ssl off in the nss_ldap config. Use the starttls URL extension instead. ldap://host/????starttls -- -- 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#6532) Support for common orderingMatching rules in extensible match filters
by daniel＠pluta.biz 29 Jul '10

29 Jul '10

Howard Chu schrieb: > The patch in the URL you specified appears to be empty. Although I'm pretty sure I've successfully uploaded the patch as I (think I) always check the URLs twice right after posting I just tried to upload it again some minutes ago using the filename: servers-slapd-schema_init_2.patch The ftp-server let me successfully log in but does not allow me to upload anything into /incoming: "425 Can't build data connection: Connection refused." Possibly this is also the cause the patch file currently seems to be empty after your download? I've tried the upload from different hosts and networks (IPv6 with IPv4 fallback) without success. Have not investigated in deep but I think it does not seem to be a problem of my/our firewalls. daniel@tingletangle:~$ ftp ftp.openldap.org Connected to www.openldap.org. 220- OpenLDAP FTP Service 220 boole.openldap.org FTP server (Version 6.00LS) ready. Name (ftp.openldap.org:daniel): anonymous 331 Guest login ok, send your email address as password. Password: 230- Copyright 1998-2010, The OpenLDAP Foundation, All Rights Reserved. 230- COPYING RESTRICTIONS APPLY, see: 230- ftp://ftp.openldap.org/COPYRIGHT 230- ftp://ftp.openldap.org/LICENSE 230 Guest login ok, access restrictions apply. Remote system type is UNIX. Using binary mode to transfer files. ftp> cd incoming 250 CWD command successful. ftp> ascii 200 Type set to A. ftp> put servers-slapd-schema_init_2.patch local: servers-slapd-schema_init_2.patch remote: servers-slapd-schema_init_2.patch 200 PORT command successful. 425 Can't build data connection: Connection refused. ftp> quit

1 0

(ITS#6610) Client receives SIGPIPE when connected via ldapi with TLS
by jzeleny＠redhat.com 28 Jul '10

28 Jul '10

Full_Name: Jan Zeleny Version: 2.4.23 OS: Linux URL: http://jzeleny.fedorapeople.org/debug/openldap/sigpipe-traces.tar.bz2 Submission from: (NULL) (209.132.186.34) When running slapd listening on local socket (ldapi:///), clients connecting to it will sometimes SIGPIPE when using TLS. This happens in about 70% times. How to reproduce: generate a pem certificate slapd -h ldapi:/// ldapsearch -H ldapi:/// -ZZ -x -d -1 I'm attaching straces from both slapd and ldapsearch. What seems to be happening is that slapd receives EAGAIN during the read from socket, marks it for another read, but then terminates a reading thread and closes the connection, while client still wants to write some data. When doing ldapsearch, it does this after result was returned, that's why it can be seen probably only in debugging mode. The issue was originally reported on 2.3.43, but I successfully reproduced it on newer versions, including 2.4.23. The only exception was Fedora rawhide version (currently 2.4.22), which is built with NSS instead of OpenSSL. NSS (and NSPR) doesn't seem to support local sockets at all, so it is not possible to use ldapi with -ZZ any more. I'm attaching straces from both successful and unsuccessful run. For complete information here is URL of relevant redhat bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=564108

1 0

(ITS#6609) Admin Guide Documentation typo's
by paul＠mawsonlakes.org 28 Jul '10

28 Jul '10

Full_Name: Paul Schulz Version: CVS OS: Linux/Ubuntu URL: Submission from: (NULL) (116.212.217.6) Patch.. diff --git a/admin/access-control.sdf b/admin/access-control.sdf index f18dba3..1ff6815 100644 --- a/admin/access-control.sdf +++ b/admin/access-control.sdf @@ -826,7 +826,7 @@ This ACL grants read permissions to authenticated users while denying others H3: Controlling rootdn access -You could specify the {{rootdn}} in {{slapd.conf}}(5) or {[slapd.d}} without +You could specify the {{rootdn}} in {{slapd.conf}}(5) or {{slapd.d}} without specifying a {{rootpw}}. Then you have to add an actual directory entry with the same dn, e.g.: @@ -876,7 +876,7 @@ One can then grant access to the members of this this group by adding appropriat > by group.exact="cn=Administrators,dc=example,dc=com" write > by * auth -Like by {[dn}} clauses, one can also use {{expand}} to expand the group name +Like by {{dn}} clauses, one can also use {{expand}} to expand the group name based upon the regular expression matching of the target, that is, the to {{dn.regex}}). For instance, diff --git a/admin/appendix-common-errors.sdf b/admin/appendix-common-errors.sdf index b285cd2..be901f1 100644 --- a/admin/appendix-common-errors.sdf +++ b/admin/appendix-common-errors.sdf @@ -11,7 +11,7 @@ H2: Common causes of LDAP errors H3: ldap_*: Can't contact LDAP server -The {[B:Can't contact LDAP server}} error is usually returned when the LDAP +The {{B:Can't contact LDAP server}} error is usually returned when the LDAP server cannot be contacted. This may occur for many reasons: * the LDAP server is not running; this can be checked by running, for example,

1 0

Re: (ITS#6531) Modify updateref to generate referrals on the backend
by hyc＠symas.com 28 Jul '10

28 Jul '10

Rein Tollevik wrote: > On 04/25/2010 12:49 AM, hyc(a)symas.com wrote: > >> Also in terms of logical abstraction the current behavior is wrong; the >> frontend should of course generate the default_referral responses but >> updateref is a per-backend item and should be generated at the backend layer. >> Ideally this would all have been fixed to behave correctly by moving all >> replication support into an overlay, where it properly belongs. As an interim >> step it would be trivial to write an updateref overlay that supersedes the >> current updateref behavior. > > Updateref processing should imo be kept out of any replication modules, > it is needed in databases where syncrepl isn't configured too. I'm > using it on my subordinate databases (with an artificial updatedn so > that slapd accepts it..) when syncrepl is configured on the superior > glue database without managing all of the subordinate databases. I.e, > the infamous test058... > > I was having the same "chain only on some of the databases" requirement > and is using a patch that allows it. I consider this patch more of a > hack than a correct solution, which is why I haven't contributed it. A > separate updateref overlay apear to me as the best solution. But for > what it's worth, my patch is now in: > > ftp://ftp.openldap.org/incoming/rein-ITS6531.patch > > An advantage with this patch over a new overlay is that it should be > usable without any configuration changes (provided the chain overlay > have already been configured in the databases and found to not work as > expected there that is ... ;-). I didn't quite follow the intended usage for this patch. Are other overlays expected to override the default over_mod_ref() handler? -- -- 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#6532) Support for common orderingMatching rules in extensible match filters
by Howard Chu 28 Jul '10

28 Jul '10

The patch in the URL you specified appears to be empty.

1 0

Re: (ITS#6607) forwarded bind failure messages cause success
by hyc＠symas.com 28 Jul '10

28 Jul '10

mbackes(a)symas.com wrote: > Full_Name: Matthew Backes > Version: RE24 > OS: > URL: > Submission from: (NULL) (76.88.107.46) > > > As noted in > > http://www.openldap.org/lists/openldap-technical/201004/msg00247.html > > setting up a chain overlay on the frontend and then configuring ppolicy with > ppolicy_forward_updates causes BIND operations with invalid credentials to > return success, apparently from the result of the chain operation. > > This is independent of the value of chain-return-error. > > WHOAMI reports anonymous after these "successful" BINDs with invalid passwords, > so there is no security compromise within the directory itself, however this has > (as noted in the above email) catastrophic results for external apps trying to > authenticate with BIND. > > This was already fixed in HEAD by back-ldap/chain.c rev 1.77 (apparently fixed for unrelated reasons). -- -- 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#6540) test022-ppolicy is flawed, masks serious stability issue
by ryans＠aweber.com 28 Jul '10

28 Jul '10

Hey Pierangelo, I just noticed http://www.openldap.org/its/index.cgi?findid=6574 - this looks like it fixes the issue I mentioned in http://www.openldap.org/its/index.cgi?findid=6540? Is that assertion correct? Ryan Steele wrote: > Hi Pierangelo, > >>> Try this patch: >>> >>> <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-29-chain.1.patch> >>> >>> It removes the offending check. I don't quite remember the reason (it >>> dates 4.5 years ago). However, I've checked and all tests pass fine, >>> including the one you pointed out. To reproduce, I modified test022 to >>> write the configuration on disk (-F option to consumer slapd); at the end >>> of the test, I tried slapd on the resulting database. Fails with >>> 2.4.22/HEAD, succeeds with this patch. >>> >>> Please test and report. >>> >>> p. > > I just wanted to see if you'd had a chance to check into this yet? As mentioned in the last ITS response, your patch > does fix the test script, but unfortunately, referrals are still not being automatically chased because the DN is not > passed correctly upstream to the read/write master. Thoughts? > -- Ryan Steele ryans(a)aweber.com Systems Administrator +1 215-825-2196 x758 AWeber Communications http://www.aweber.com

1 0

Re: (ITS#6540) test022-ppolicy is flawed, masks serious stability issue
by ryans＠aweber.com 28 Jul '10

28 Jul '10

Hi Pierangelo, >> Try this patch: >> >> <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-29-chain.1.patch> >> >> It removes the offending check. I don't quite remember the reason (it >> dates 4.5 years ago). However, I've checked and all tests pass fine, >> including the one you pointed out. To reproduce, I modified test022 to >> write the configuration on disk (-F option to consumer slapd); at the end >> of the test, I tried slapd on the resulting database. Fails with >> 2.4.22/HEAD, succeeds with this patch. >> >> Please test and report. >> >> p. I just wanted to see if you'd had a chance to check into this yet? As mentioned in the last ITS response, your patch does fix the test script, but unfortunately, referrals are still not being automatically chased because the DN is not passed correctly upstream to the read/write master. Thoughts? -- Ryan Steele ryans(a)aweber.com Systems Administrator +1 215-825-2196 x758 AWeber Communications http://www.aweber.com

1 0

Re: (ITS#6599) slapd not responding
by binoy＠cordys.com 28 Jul '10

28 Jul '10

Hi, In short, this works: Deleting cn=Test0,cn=Test0,cn=soap nodes,o=system,cn=cordys,cn=t274,o=vanenburg.com Deleted cn=Test0,cn=Test0,cn=soap nodes,o=system,cn=cordys,cn=t274,o=vanenburg.com While this fails: Deleting cn=Test2,cn=soap nodes,o=system,cn=cordys,cn=t274,o=vanenburg.com Searching cn=Test2,cn=Test2,cn=soap nodes,o=system,cn=cordys,cn=t274,o=vanenburg.com 0 (objectclass=*) Searched cn=Test2,cn=Test2,cn=soap nodes,o=system,cn=cordys,cn=t274,o=vanenburg.com 0 (objectclass=*) LDAP Connection error happend LDAPException: Connection lost waiting for results from cin0575.vanenburg.com:6,366 (91) Connect Error java.net.SocketException: Connection reset Thanks and regards, Binoy Joseph

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs