openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

Re: (ITS#5362) syncrepl provider kills consumer by sending truncated cookie
by hyc＠symas.com 09 Feb '08

09 Feb '08

quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.7 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (24.23.156.219) > > > As reported in the Debian BTS, and Howard has seen this as well: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464024 Also, as usual, a GDB stack trace from a slapd with debug symbols would be useful. strace is generally useless since it only traces system calls, not application code. I wish whoever is telling people to provide strace output would quit that. -- -- Howard Chu Chief Architect, 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#5362) syncrepl provider kills consumer by sending truncated cookie
by hyc＠symas.com 09 Feb '08

09 Feb '08

quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.7 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (24.23.156.219) > > > As reported in the Debian BTS, and Howard has seen this as well: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464024 I saw a similar problem while investigating ITS#5332. While ldapadd'ing 1000 entries I saw several instances where a cookie was sent without a CSN. It didn't result in a crash though. After sprinkling some assert's in the code I think I've identified the problem, and the current code in HEAD no longer triggers any of the assert's that I used. But I'm not certain that the behavior I was chasing is the same as in this bug report. Please test and report your results. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5362) syncrepl provider kills consumer by sending truncated cookie
by quanah＠OpenLDAP.org 09 Feb '08

09 Feb '08

Full_Name: Quanah Gibson-Mount Version: 2.4.7 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.23.156.219) As reported in the Debian BTS, and Howard has seen this as well: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464024

1 0

Re: (ITS#5344) Wrong check for bad Modify DN
by ando＠sys-net.it 09 Feb '08

09 Feb '08

h.b.furuseth(a)usit.uio.no wrote: > hyc(a)symas.com writes: >>> The slapd/modrdn.c check for affectsMultipleDSAs is insufficient, it >>> requires newSuperior to be in the same backend. That does not catch >>> moving "cn=x,cn=y" to another database's suffix "cn=z,cn=y". >> I don't see how it can miss this. > > It checks if newSuperior is in another backend, but that move doesn't > need a newSuperior. It keeps the same parent: > > database 1: suffix cn=y > database 2: suffix cn=z,cn=y > modify rdn: dn "cn=x,cn=y"; newrdn cn=z; newSuperior (if any) cn=y. > >> Probably should look at adding the dest_dn to the op struct, so each >> backend doesn't have to rebuild it. > > Indeed. And dest_ndn. You should apply your initial patch (to HEAD, 2.4), then modify HEAD to pass dest_dn/dest_ndn 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5361) cert verification failures with GnuTLS and DNS subjectAltName
by steve.langasek＠canonical.com 08 Feb '08

08 Feb '08

Full_Name: Steve Langasek Version: 2.4.7 OS: Debian URL: http://people.ubuntu.com/~vorlon/gnutls-altname-nulterminated.patch Submission from: (NULL) (2001:4830:1244:0:219:d2ff:fe76:2acb) When built with GnuTLS, libldap fails to correctly verify DNS hostnames against the subjectAltName field of the provided certificate. The reason for this is that, while the "length" that gnutls returns for the CN is equal to the strlen(), the length returned by gnutls_x509_crt_get_subject_alt_name() includes a trailing NUL. I have verified that the referenced patch corrects this for the case of non-wildcard DNS subjectAltName values. I have not tested the code for the wildcarded case, though it seems likely that the same bug applies there and will need to be fixed.

1 0

(ITS#5360) wrong default for TLSVerifyClient (with GnuTLS?)
by steve.langasek＠canonical.com 08 Feb '08

08 Feb '08

Full_Name: Steve Langasek Version: 2.4.7 OS: Debian URL: http://people.ubuntu.com/~vorlon/slapd-tlsverifyclient-default.patch Submission from: (NULL) (2001:4830:1244:0:219:d2ff:fe76:2acb) The code in slapd whose purpose is to override the library default value for LDAP_OPT_X_TLS_REQUIRE_CERT is failing, at least when OpenLDAP is built with GnuTLS, because the override is done to a set of "global" options which are never used. The patch referenced below has been verified to fix this issue.

1 0

(ITS#5359) Add BDB encryption support
by hyc＠OpenLDAP.org 08 Feb '08

08 Feb '08

Full_Name: Howard Chu Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc Encryption support was added to HEAD on 2007-12-15. Just filing this here for tracking purposes. Some discussion followed here http://www.openldap.org/lists/openldap-devel/200712/msg00082.html

1 0

Re: (ITS#5339) wrong referral from back-bdb
by h.b.furuseth＠usit.uio.no 08 Feb '08

08 Feb '08

Howard Chu writes: >Hallvard B Furuseth wrote: >>hyc(a)symas.com writes: >>> Frankly this whole example doesn't make sense, and RFC4511 doesn't say >>> anything specific about it. >> >> Yes it does. Section 4.1.10. Referral: >> - If the<dn> part is present, the client uses this name in its next >> request to progress the operation, and if it is not present the >> client uses the same name as in the original request. > > Yes, I saw that. But the text doesn't give any explanation of the > ramifications of what it's describing. Which is what I'm complaining > about here. Take it up with ldapext:-) And I guess we could make a slapd.conf option which turns on your preferred way. The ramifications are that things can break, I think. In particular DN-valued attributes in the search result or in an Add request. The server can't help with that either, the client would have to handle it. Also, now that I think of it, back-hdb/ldif subtree rename is broken if there are referral objects with DNs in the subtree. So I guess the slapd.conf option should allow to strip DNs that match the entry DN. And maybe allow to be more paranoid about rewriting writes (and Binds?) than searches. However... >> Both RFCs disagree. > > They are wrong. Or at least, under-specified. In X.501 section 17.3 > "Directory Distribution Model" it's quite clear that all of the > components of a distributed directory must belong to a single DIT. Which is not true in the LDAP world, and I don't know about today's X.500 world. Nameflow died and Dante was unable to resurrect it. Maybe the X.500 world has also switched to 'dc' structure, I don't know. Anyway, LDAP is not X.500. Remember, LDAP referrals need not even be LDAP URLs. My guess is that's one reason for the difference from X.500: When you can even return a HTTP URL, why should you _not_ be allowed to return a far smaller change from the original URL? Also LDAP started out a lot sloppier than X.500. Getting some response which hopefully resembled what you wanted was better than none:-) > And again, the service model requires the directory to store the > client's data without any alteration. If the client wants to create > the entry "cn=me,o=we" either that exact entry must be created, or the > operation must fail. Well, the operation does fail in the original server. Then the client may try another operation at another server... I don't know if that's a valid interpretation of the service model or not. In any case, it's a detail compared to the mess -- Hallvard

1 0

Re: (ITS#5354) slapd repeatedly hangs and stops reponding
by orenl＠cs.columbia.edu 08 Feb '08

08 Feb '08

Howard Chu wrote: > Oren Laadan wrote: >> Howard Chu wrote: >>> This discussion has wandered off of potential bugs and into regular >>> software usage. You should pick this up again on the -software mailing >>> list. This ITS will be closed. >> >> Well, the fact is that as far as I can tell the meta-URIs are not >> mis-configured, the server works well for some random amount of time >> and then reaches a lockup. True, the configuration isn't the optimal >> in terms of performance. However, in the absence of text in the man >> pages that prohibits doing so, the observed behavior is buggy. >> >> In fact, there is at least one example in the archives of -software >> that discusses a deployment of meta with "uri ldap://localhost/" that >> seems to have gone ok without too much criticism: >> http://www.openldap.org/lists/openldap-software/200301/msg00112.html) > > The URIs in that example clearly do not overlap with the actual meta > database. It's also not stated in the example, but it's most likely that > that example is directing queries to a separate slapd process. In your > config, your URIs clearly *do* overlap with your meta database, which > guarantees an infinite loop. True. The guy is merging three subtrees into a single tree to a common root, while I try to merge two database that into the exact same DN. > >> To that I'll add, that to the best of my knowledge and after reading >> and re-reading the docs and the man-pages, I cannot find another way >> to merge two databases (not distinct subtrees) such that a local db >> adds entries to a remote db, but to use meta. > > You haven't provided any information to explain why you cannot structure > your additional entries as a distinct subtree. You're still just > handwaving when we ask for concrete examples of the entries involved. Clearly I'm new to LDAP. Please indicate what information is missing, I'll be happy to provide, even the local database (my .ldif file) and sample queries from the remote server. Just name it. Taking a step back: we have a departmental LDAP server for user auth, (posix) groups, autofs maps and so on. In my group, we add to the DB groups and autofs maps that do not exist on the remote server, so a user on our machines can belong to additional groups. I am not arguing that I cannot structure it differently. I simply do not know if I can structure it differently. Ideally I could add entries to the remote database, but that is impossible. The remote server gives DN dc=MAIN,dc=EXAMPLE,dc=COM, which is what I made the local server give (via the meta backend) and which is what the clients are using as their base DN. The local database (.ldif file) currently looks like this, in this example adding the group LOCAL_GRP with user USER1 USER2 (there are more entries, also for autofs maps, but I think this explains the idea). # root/base dn: dc=ABC,dc=MAIN,dc=EXAMPLE,dc=COM dc: EXAMPLE objectClass: top objectClass: domain # group subtree dn: ou=Group,dc=ABC,dc=MAIN,dc=EXAMPLE,dc=COM ou: Group objectClass: top objectClass: organizationalUnit # specific group information dn: cn=LOCAL_GRP,ou=Group,dc=ABC,dc=MAIN,dc=EXAMPLE,dc=COM cn: LOCAL_GRP objectClass: posixGroup objectClass: uidObject gidNumber: 1000 memberUid: USER1 memberUid: USER2 uid: root > The best of your knowledge clearly didn't get you very far or you > wouldn't have been asking for help in the first place. For you to > second-guess the folks trying to help you and omit the information > requested really isn't very productive. No need to make it a personal. I'm new to LDAP, but not clueless either. I truly appreciate the time and efforts that you guys are putting into this issue (and ldap in general). I only omit information because I'm not aware of its importance to you. It helps if you indicate what's missing, and I'll provide promptly, as I've been doing so far. > >> So: the config seems fine (see the original ticket), I need to use meta, >> but it exhibits random lockups. Using a suboptimal solution is not a >> bug. Random lockups are a symptom of a bug :( > > No. Lockups due to thread exhaustion are a symptom of a bad configuration. I then suggest that this specific issue be mentioned in the ldap-meta man-page (as it is now, it doesn't read so), for the sake of others. > >> (That said, I will ask on the -software list with regard to alternative >> configurations, as you suggest). (also sent a message to the -software list as you suggested; made it with shorted DN for simplicity) Thanks, Oren.

1 0

Re: (ITS#5339) wrong referral from back-bdb
by hyc＠symas.com 08 Feb '08

08 Feb '08

Hallvard B Furuseth wrote: > hyc(a)symas.com writes: >> Frankly this whole example doesn't make sense, and RFC4511 doesn't say >> anything specific about it. > > Yes it does. Section 4.1.10. Referral: > - If the<dn> part is present, the client uses this name in its next > request to progress the operation, and if it is not present the > client uses the same name as in the original request. Yes, I saw that. But the text doesn't give any explanation of the ramifications of what it's describing. Which is what I'm complaining about here. >> A referral is not an alias. If I try to add an entry "cn=me,o=we" then >> that is the DN that the entry must be created with. If something >> redirects me to create "cn=me,o=they" this should be an error - that >> is not the entry I requested the server to create. > Both RFCs disagree. They are wrong. Or at least, under-specified. In X.501 section 17.3 "Directory Distribution Model" it's quite clear that all of the components of a distributed directory must belong to a single DIT. And again, the service model requires the directory to store the client's data without any alteration. If the client wants to create the entry "cn=me,o=we" either that exact entry must be created, or the operation must fail. > RFC 4511 4.1.10. Referral: > - It is RECOMMENDED that the<dn> part be present to avoid ambiguity. > RFC 3296 section 2.2 (about 'ref'): > The LDAP URL SHOULD contain a non-empty DN. The handling of LDAP > URLs with absent or empty DN parts or with explicit scope specifier > is not defined by this specification. > RFC 3296 Section 5.2: > The DN part MUST be modified such that it refers to the appropriate > target in the referenced server (as detailed below). Even where the > DN to be returned is the same as the target DN, the DN part SHOULD > NOT be trimmed. The X.500 model does not allow for arbitrary DNs to be inserted here. The RFC text implies that arbitrary DNs are allowed, but that's incorrect. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

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