openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

Re: (ITS#6242) PCache cache corruption
by karavelov＠spnet.net 25 Sep '09

25 Sep '09

Hello, I have got the same errors plus additional abort on assertion using differend configuration. I have decided to split slapd functions in 2 daemons: 1st instance of slapd is configured with back-sql and listent to unix domain socket 2nd instance is a proxy to the first instance with pcache overlay - it servers clients. The config of the slapd with sql backend could be found here: http://purgatory.spnet.net/~karavelov/proxy/slapd.conf It works without any error The config of the proxy could be found here: http://purgatory.spnet.net/~karavelov/proxy/slapd-proxy.conf It countinues to corrupt random records in the cache. A full log of the slapd could be found here: http://purgatory.spnet.net/~karavelov/proxy/debug-rubella.bg For the failing record look for: filter="(&(objectClass=mailDomain)(dc=rubella.bg))" Additionally, now it aborts on assertion at random times. The output of the server could be found here: http://purgatory.spnet.net/~karavelov/proxy/slapd-abort Started in background it emits a lot of ld warnings like the one in the beginning of the latest file Thanks in advance for any help and suggestions Luben

1 0

Re: (ITS#6304) Slapd freezes during SSL handshake when TLSVerifyClient=allow
by hyc＠symas.com 24 Sep '09

24 Sep '09

jzeleny(a)redhat.com wrote: > Full_Name: Jan Zeleny > Version: 2.4.18 > OS: Fedora 11 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (62.40.79.66) > Following bug report is a good introduction to the issue: > https://bugzilla.redhat.com/show_bug.cgi?id=509230 > > I managed to reproduce it simply by turning on TLS and setting TLSVerifyClient > allow. In that configuration local connections to ldaps still work, but > connections from remote machines don't work in about 80-90% cases. > > I tried to trace the bug, so far I found that when using this option, slapd > sends it's certificate to TCP socket and gets the EAGAIN in the middle of > writing. After that it goes to epoll_wait and there it waits indefinitely. I > suspect the EAGAIN happens because TCP socket is full or something like that. > Notice that when you turn on debugging information about packet handling, this > issue disappears - maybe socket has time to get empty? > > I tried and confirmed the bug in several versions of openldap (incl. 2.4.18) and > several Linux distributions to eliminate the possibility this issue is caused by > some other component or it was solved already. I'm unable to reproduce this using slapd on a debian x86-64 system, whether on the local LAN or from 13 hops away. I've also used the tcp-buffer option to set a minimum sized socket buffer and still could not duplicate the problem. You will need to provide more explicit information on how to reproduce this issue. Perhaps providing a set of CA/server certs will also be necessary. Please note that the bug report you reference (509230) gives inconsistent information; it says that no hang occurs with -d2, but that hangs occur with no diagnostics, even with -d -1. Obviously -d -1 includes -d 2, so: does it hang, or not, with -d -1? -- -- 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#6306) Problems compiling OpenLDAP in 64 bit due to old libtool version included
by dam＠opencsw.org 24 Sep '09

24 Sep '09

Full_Name: Dagobert Michelsen Version: 2.4.18 OS: Solaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (86.103.225.254) There is a problem compiling the current OpenLDAP (2.4.18) in 64 bit on Solaris. The problem occurs when building with modules and enabling 64 bit in CFLAGS rather than setting CC to the compiler including flags. The source of the problem is the old libtool version 1.5.x included in OpenLDAP. The libtool maintainers recommended upgrading libtool to at least 2.2 where the problem was fixed. The corresponding libtool thread is available at <http://lists.gnu.org/archive/html/bug-libtool/2009-09/msg00017.html> This is the excerpt of my tests: This works fine: ./configure CC='/opt/studio/SOS11/SUNWspro/bin/cc -xarch=v9' CPPFLAGS='-I/opt/csw/include' LDFLAGS='-L/opt/csw/lib/64 -R/opt/csw/ lib/64' && gmake And it also works with modules: ./configure CC='/opt/studio/SOS11/SUNWspro/bin/cc -xarch=v9' CPPFLAGS='-I/opt/csw/include' LDFLAGS='-L/opt/csw/lib/64 -R/opt/csw/ lib/64' --enable-modules && gmake Without modules this works also: ./configure CC='/opt/studio/SOS11/SUNWspro/bin/cc' CFLAGS='-xarch=v9' CPPFLAGS='-I/opt/csw/include' LDFLAGS='-L/opt/csw/lib/64 -R/opt/csw/ lib/64' && gmake This does not work: ./configure CC='/opt/studio/SOS11/SUNWspro/bin/cc' CFLAGS='-xarch=v9' CPPFLAGS='-I/opt/csw/include' LDFLAGS='-L/opt/csw/lib/64 -R/opt/csw/ lib/64' --enable-modules && gmake For now this tiny patch fixed my problem, but it needs to be worked on for general usage: diff -Naur openldap-2.4.17.orig/build/ltmain.sh openldap-2.4.17.patched/build/ltmain.sh --- openldap-2.4.17.orig/build/ltmain.sh 2009-01-22 01:00:41.000000000 +0100 +++ openldap-2.4.17.patched/build/ltmain.sh 2009-09-11 14:26:06.136891084 +0200 @@ -4745,7 +4745,10 @@ case "$compile_command " in *" -static "*) ;; *) pic_flag_for_symtable=" $pic_flag";; - esac + esac;; + *-*-solaris*) + LTCFLAGS="$compiler_flags" + ;; esac # Now compile the dynamic symbol file.

1 0

Re: (ITS#6305) slapo-chain(5): description for chain-rebind-as-user missing
by ghenry＠OpenLDAP.org 24 Sep '09

24 Sep '09

----- michael(a)stroeder.com wrote: > Full_Name: Michael Str=EF=BF=BDder > Version: HEAD > OS:=20 > URL:=20 > Submission from: (NULL) (84.163.127.85) >=20 >=20 > In slapo-chain(5) there is no descriptive text for configuration > directive > 'chain-rebind-as-user' yet like for the other directives. Thanks, Will take a look. --=20 Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

(ITS#6305) slapo-chain(5): description for chain-rebind-as-user missing
by michael＠stroeder.com 24 Sep '09

24 Sep '09

Full_Name: Michael Ströder Version: HEAD OS: URL: Submission from: (NULL) (84.163.127.85) In slapo-chain(5) there is no descriptive text for configuration directive 'chain-rebind-as-user' yet like for the other directives.

1 0

Re: (ITS#6303) Buffer overflow with new glibc
by h.b.furuseth＠usit.uio.no 24 Sep '09

24 Sep '09

jzeleny(a)redhat.com writes: > I guess new version of glibc has some kind of mechanism which is > checking boundaries of structures and isn't allowing write out of > those boundaries. Could you test if this works instead? http://folk.uio.no/hbf/ol-struct-hack-1.patch If that doesn't work, similar code elsewhere may be in danger. Not that it's important in this case since the back-ldif code isn't run often. It just avoids one malloc, one check for whether that succeeded, and one free. Your patch forgot the last two. Actually the boundary check you mention is exactly the problem the BVL_NAME macro avoids, though I'm not sure why I didn't just use the standard "struct hack". Maybe the problem is with padding bytes after fname. Anyway, I suppose this means the old "struct hack" is now definitely getting dangerous to use. Whatever is going on, I'd like to find out. Which versions of gcc and glibc, and which architecture is this? (32-bit i683, 64-bit amd, etc). And if it doesn't take much time, could you try if these variants fix the problem too? http://folk.uio.no/hbf/ol-struct-hack-2.patch http://folk.uio.no/hbf/ol-struct-hack-3.patch I don't plan to use them, we can use your variant if my first patch doesn't work. I'm just curious what's going on. -- Hallvard

1 0

(ITS#6304) Slapd freezes during SSL handshake when TLSVerifyClient=allow
by jzeleny＠redhat.com 24 Sep '09

24 Sep '09

Full_Name: Jan Zeleny Version: 2.4.18 OS: Fedora 11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.40.79.66) Following bug report is a good introduction to the issue: https://bugzilla.redhat.com/show_bug.cgi?id=509230 I managed to reproduce it simply by turning on TLS and setting TLSVerifyClient allow. In that configuration local connections to ldaps still work, but connections from remote machines don't work in about 80-90% cases. I tried to trace the bug, so far I found that when using this option, slapd sends it's certificate to TCP socket and gets the EAGAIN in the middle of writing. After that it goes to epoll_wait and there it waits indefinitely. I suspect the EAGAIN happens because TCP socket is full or something like that. Notice that when you turn on debugging information about packet handling, this issue disappears - maybe socket has time to get empty? I tried and confirmed the bug in several versions of openldap (incl. 2.4.18) and several Linux distributions to eliminate the possibility this issue is caused by some other component or it was solved already.

1 0

(ITS#6303) Buffer overflow with new glibc
by jzeleny＠redhat.com 24 Sep '09

24 Sep '09

Full_Name: Jan Zeleny Version: 2.4.18 OS: Fedora 12 URL: http://jzeleny.fedorapeople.org/patches/openldap/openldap-2.4.18-ldif-buf-o… Submission from: (NULL) (62.40.79.66) I tried to make configuration directory (instead of config file) work in Fedora 12. I noticed that new builds of slapd fail during start with config dir. The start results in SIGABRT, backtrace and buffer overflow error. I traced the bug to ldif.c. I guess new version of glibc has some kind of mechanism which is checking boundaries of structures and isn't allowing write out of those boundaries. I made attached patch to avoid the issue. After testing it seems to be working well.

1 0

Re: (ITS#6301) PATCH - used red-black tree for response messages
by bduncan＠apple.com 23 Sep '09

23 Sep '09

On Sep 22, 2009, at 5:07 PM, Howard Chu wrote: > bduncan(a)apple.com wrote: >> Full_Name: Bryan Duncan >> Version: 2.4.16 >> OS: Mac OS X 10.6 >> URL: ftp://ftp.openldap.org/incoming/bryan-duncan-rbtree-090922.patch >> Submission from: (NULL) (17.224.21.109) >> >> >> Uploaded patch that replaces the linked-list of response messages >> with a >> red-black tree. This improves performance since random access to >> the response >> messages is needed. >> > Hmm, there is no such file at the above URL. Hmmm... there's some issue ftp'ing it up. New URL: http://public.me.com/bryan.duncan/bryan-duncan-rbtree.090922.patch > > Also, while I don't doubt that a tree structure beats a linked list > for performance, could you please describe the analysis that led you > to writing this patch? What problem were you tracking, and what > situation caused it? When running performance benchmarks we noticed one process was consuming huge amount (75%) of the CPU. Further analysis revealed two problems: 1) the vast majority of those cycles were spent in ldap_msgdelete(), walking the response message linked-list. 2) There was a lot of contention for the thread mutex that's held while the message list is walked. Thus we needed to reduce the time spent walking the list in order to achieve the desired performance. After switching to the red-black tree we saw CPU utilization for the process was down in the noise. > > Why did you use a red-black tree, rather than just using the AVL > code that's already in the source? I had a red-black tree implementation I knew had been tuned for performance and has been in shipping software. I'm not saying the OpenLDAP AVL code couldn't handle it. I could only implement one or the other, so I chose the one I was familiar with. > > In the future it would be a good idea to raise these topics on the > openldap-devel mailing list before diving in, since this is core > functionality and performance-related. Performance patches don't get > committed without test results showing a clear before/after gain. Yes, that's a good idea. My apologies for not raising the issue sooner. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ Bryan Duncan Apple

1 0

Re: (ITS#6299) Support for RFC 4529 in slapo-allowed
by masarati＠aero.polimi.it 23 Sep '09

23 Sep '09

> masarati(a)aero.polimi.it wrote: >>> If the client wants to request via slapo-allowed which attributes are >>> readable/writeable before adding another object class then object >>> classes >>> not >>> yet part of the entry could be used if the client adds the object class >>> name >>> prefixed with @. This is an extension to the semantics but should not >>> cause any >>> problem with existing clients. >> >> with the current implementation of slapo-allowed, the client does not do >> anything specific but requesting those special operational attributes. > > Yes. That's what I've implemented. Well, what slapo-allowed and MS AD > implement is limited anyway. E.g. no way to determine writeable attrs when > adding new entries. > >> It is not clear to me how the semantics you propose should be activated. >> If you mean that having some "@" + <objectClass> in the requested attrs >> should populate the allowedAttributes and allowedAttributesEffective >> attributes, I think it would be a significant distortion of the meaning >> of >> the requested attributes. > > Yes, my suggestion was that slapo-allowed looks at the attr list in the > search > request for occurences of "@" + <objectClass>. And then use each > <objectClass> > (if not yet in the set of current object classes of the entry) to evaluate > the > accompanying attrs and put them into allowedAttributes and/or > allowedAttributesEffective. > > Yes, that's a change in the current semantics. Not only a change in semantics, but also a poor choice, IMHO. How can the server determine whether a request is malformed or the client really wanted to trigger such an esoteric feature? > I now partially worked around the problem with new object classes in > web2ldap > by determining which attrs would be really new when adding a set of object > classes enabling all the input fields for these new attrs. But off course > that's not nice. > >> I'd rather favor defining a specific control request, that sort of >> "mimics" adding some attributes, including objectClass values, to an >> existing entry, so that allowedAttributes and allowedAttributesEffective >> are populated accordingly. > > There are some implementations of the Get Effective Rights control but > they > seem to slightly differ. That control's definition really sounds like an overkill, although I understand the intention of allowing clients to specify everything a DSA could use to determine access privileges. I'd favor a much lighter control. Perhaps, all the features allowed by that spec, and even more and better (possibly with a flexible mechanism) could be made optional. In any case, it should be clear that the result will only be a hint, or a guess, and the only reliable way to determine read access would be to actually read data, and, to determine write access, to attempt the operation using the noOp control. p.

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