openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

(ITS#5405) syncprov psearch race condition
by hyc＠OpenLDAP.org 07 Mar '08

07 Mar '08

Full_Name: Howard Chu Version: 2.4 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc It's possible for a new update to be recorded after the syncprov_qtask has examined its response queue but before it has removed itself from the slapd runqueue. In this case, the qtask will not process the new response right away, it won't see it until the next time an operation occurs on the server.

1 0

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

07 Mar '08

Hallvard B Furuseth wrote: > Howard Chu writes: >> h.b.furuseth(a)usit.uio.no wrote: >>> Howard Chu writes: >>>>> 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. >> RFC4510 Section 2 "Relationship to X.500" >> (...) An LDAP server MUST act in accordance with the X.500 (1993) >> series (...) > > Except when it doesn't. Like the various implications of sending text > instead of ASN.1 and numeric OIDs. That's irrelevant. The service model and the on-the-wire encoding are two completely different things. The encoding of LDAP is of course different from DAP, but both are required to provide the same service model. Just as DSML is encoded differently, but still delivers the X.500 service model. >> (...) LDAPv1 had no referrals. When they were introduced in LDAPv2 >> it's clear that nobody knew what they were doing, or nobody wanted to >> tackle the glaring absence of an analogue to X.500 DSP. > LDAPv2 (the standard) has no referrals. The Umich implementation > introduced them as a hack: It stuffed them into the errorMessage field. > LDAPv3 moved them into the standard. And speaking for my own little > corner of the standardization process, I definitly was ignorant about > them and wanted nothing to do with them. I've still never had any use > for LDAP referrals. > >> They should never have been introduced. We're stuck with them for >> now, but we can at least try to make them make sense. > > Well, take it up with ldapext. And add an option to slapd to reject > attempts to add 'ref' attrs with a DN, or whatever. > > For now, once the directory contains a 'ref' URL which includes the DN, > I don't see any reason not to rewrite like the spec says. Whatever the > "right answer" is, a referral with an un-rewritten DN seems worse than > with a rewritten one. > Regarding the branches of bdb_referrals() and ldif_back_referrals() > which rewrite default_referral: I suggest we delete it. > The back-ldif code breaks exactly as one would expect: With > referral ldap://urgle/ > database ldif > suffix o=foo > and an empty database, ldapcompare cn=bar,o=foo gives a referral to > urgle. So does ldapadd of o=foo:-( I seem to remember someone meant > the latter was correct and there was a control to prevent it at some > point, maybe that is related. back-bdb has a test which prevents this > referral in case of the suffix dn, but not for superior DNs. But I > don't see why it would not be just as buggy for superiors, if it could > happen. Yeah, I noticed that in the source recently and thought that was bogus. The default referral was only supposed to be used when fielding a query for a completely unknown naming context. However, e.g. back-bdb tries to use the default referral whenever a requested entry does not exist, and leaves it to the frontend to turn that result back into NoSuchObject as appropriate. For cases where the context is known, but no data is present, it should just return NoSuchObject. Sending the client off to who-knows-where is completely wrong in this case. And of course, there should have been genuine X.500-style knowledge references, explicitly set for superior, peer, and subordinate DSAs. Any request that doesn't match the known naming contexts, or any of the explicitly defined knowledge references, should simply fail with NoSuchObject. The notion of "default referral" is just sloppy all around. -- -- 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#5339) wrong referral from back-bdb
by h.b.furuseth＠usit.uio.no 07 Mar '08

07 Mar '08

I wrote: > And speaking for my own little corner of the standardization process, > I definitly was ignorant about them and wanted nothing to do with > them. I've still never had any use for LDAP referrals. Hmm. Now that I think of it, that's not true. I did get involved in the details, sort of, but indeed not with the "big picture". It's just in real life I never used them, so to me it was almost a purely theoretical exercise. -- Hallvard

1 0

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

07 Mar '08

Howard Chu writes: >h.b.furuseth(a)usit.uio.no wrote: >>Howard Chu writes: >>>> 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. > > RFC4510 Section 2 "Relationship to X.500" > (...) An LDAP server MUST act in accordance with the X.500 (1993) > series (...) Except when it doesn't. Like the various implications of sending text instead of ASN.1 and numeric OIDs. > (...) LDAPv1 had no referrals. When they were introduced in LDAPv2 > it's clear that nobody knew what they were doing, or nobody wanted to > tackle the glaring absence of an analogue to X.500 DSP. LDAPv2 (the standard) has no referrals. The Umich implementation introduced them as a hack: It stuffed them into the errorMessage field. LDAPv3 moved them into the standard. And speaking for my own little corner of the standardization process, I definitly was ignorant about them and wanted nothing to do with them. I've still never had any use for LDAP referrals. > They should never have been introduced. We're stuck with them for > now, but we can at least try to make them make sense. Well, take it up with ldapext. And add an option to slapd to reject attempts to add 'ref' attrs with a DN, or whatever. For now, once the directory contains a 'ref' URL which includes the DN, I don't see any reason not to rewrite like the spec says. Whatever the "right answer" is, a referral with an un-rewritten DN seems worse than with a rewritten one. Regarding the branches of bdb_referrals() and ldif_back_referrals() which rewrite default_referral: I suggest we delete it. The back-ldif code breaks exactly as one would expect: With referral ldap://urgle/ database ldif suffix o=foo and an empty database, ldapcompare cn=bar,o=foo gives a referral to urgle. So does ldapadd of o=foo:-( I seem to remember someone meant the latter was correct and there was a control to prevent it at some point, maybe that is related. back-bdb has a test which prevents this referral in case of the suffix dn, but not for superior DNs. But I don't see why it would not be just as buggy for superiors, if it could happen. -- Hallvard

1 0

Re: (ITS#5391) hdb deadlock
by h.b.furuseth＠usit.uio.no 07 Mar '08

07 Mar '08

hyc(a)symas.com writes: > One thing that I've started doing recently in my configs is to skip > the #bytes option (leave it zero), so that only time-based checkpoints > occur. Since they're done in a dedicated task, only one thread at a > time can trigger a checkpoint. How about making #bytes-based checkpoints signal or (pthread_kill?) the timed checkpoints thread, so that thread can handle all checkpoints? -- Hallvard

1 0

(ITS#5404) back-ldap fails intermittently with 80 Internal (implementation specific) error
by toby＠inf.ed.ac.uk 07 Mar '08

07 Mar '08

Full_Name: Toby Blake Version: 2.3.38 amd 2.3.40 OS: Fedora Core 5 and Fedora Core 6 URL: Submission from: (NULL) (129.215.218.33) Hi there, We're seeing a (seemingly) intermittent problem when using back-ldap (with or without using the pcache overlay for caching), where 1 in x queries fail with "result: 80 Internal (implementation specific) error", where x is anywhere between 2 and 10. We're seeing this with both openldap-2.3.38 and openldap-2.3.40 - running on Fedora Core 5 and 6. The remote server is running FC5, openldap 2.3.38. I currently have a machine exhibiting this problem - it's a machine in a student lab. The database part of slapd.conf on this machine is: database ldap suffix dc=inf,dc=ed,dc=ac,dc=uk rootdn uid=ldaprep/inganoust.inf.ed.ac.uk,cn=inf.ed.ac.uk,cn=gssapi,cn=auth uri ldap://testdir.inf.ed.ac.uk/ idassert-bind mode=none bindmethod=sasl saslmech=GSSAPI idassert-authzFrom "dn:*" I'm afraid I can't currently reproduce this error, but hopefully some of the information below will help... I've done some stepping through the code and what seems to be happening when the error occurs is that the call to getpeername in ldap_host_connected_to in libraries/libldap/os-ip.c:590 fails with errno=107 "transport endpoint is not connected" and thereafter ldap_int_sasl_open (cyrus.c:518) is called with NULL as the 'host' argument (in our case it should be 'hadrian.inf.ed.ac.uk') - this results in LDAP_LOCAL_ERROR being returned. The backtrace (in ldap_host_connected_to) is: (gdb) bt #0 ldap_host_connected_to (sb=0xb4124950, host=0x81b0efb "localhost") at os-ip.c:586 #1 0x081394b5 in ldap_int_sasl_bind (ld=0xb4131058, dn=0x0, mechs=<value optimized out>, sctrls=0x0, cctrls=0x0, flags=2, interact=0x81293b0 <lutil_sasl_interact>, defaults=0x892df98) at cyrus.c:643 #2 0x0813b45d in ldap_sasl_interactive_bind_s (ld=0xb4131058, dn=0x0, mechs=0x88bef98 "GSSAPI", serverControls=0x0, clientControls=0x0, flags=2, interact=0x81293b0 <lutil_sasl_interact>, defaults=0x892df98) at sasl.c:479 #3 0x08109625 in ldap_back_dobind_int (lcp=0xb370e0a8, op=0x8952900, rs=0xb370f1c4, sendok=<value optimized out>, retries=0, dolock=1) at bind.c:1997 #4 0x080dab4b in ldap_back_search (op=0x8952900, rs=0xb370f1c4) at search.c:166 #5 0x0806317f in fe_op_search (op=0x8952900, rs=0xb370f1c4) at search.c:355 #6 0x08063b31 in do_search (op=0x8952900, rs=0xb370f1c4) at search.c:217 #7 0x08061209 in connection_operation (ctx=0xb370f238, arg_v=0x8952900) at connection.c:1133 #8 0x081322f3 in ldap_int_thread_pool_wrapper (xpool=0x88a1d18) at tpool.c:478 #9 0x00db145b in start_thread () from /lib/libpthread.so.0 #10 0x001cf23e in clone () from /lib/libc.so.6 (gdb) When getpeername returns the error, it is always for the same 'sd' value - on the machine I'm looking at, it's 13, e.g. 590 if ( getpeername( sd, sa, &len ) == -1 ) { (gdb) p sd $3 = 13 (gdb) p errno $4 = 107 (gdb) What's interesting here is that if I use lsof to see the filehandles that slapd is holding open, I see this for FD 13: COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME slapd 2551 ldap 13u sock 0,5 3603708 can't identify protocol Interestingly, this is the exact same output I see from lsof if a socket() has been created, but not connect()ed. It appears then, that a socket of this type gets into the pool of connections to the remote server being used by the local slapd, thus explaining the 1 in x failure rate - as it cycles through the pool. I currently have a machine in this state, so if there's more information I could usefully provide, then let me know. I can of course change the loglevel, but that would involve restarting slapd on this machine - which fixes the problem. Anyway, let me know if there's more I can do - I can experiment on other machines. Cheers Toby Blake School of Informatics University of Edinburgh

1 0

Re: (ITS#5403) LDAP_OPT_X_SASL_SSF 64bit bugfix or workaround
by h.b.furuseth＠usit.uio.no 07 Mar '08

07 Mar '08

More detail in "private" ITS#3864. -- Hallvard

1 0

(ITS#5403) LDAP_OPT_X_SASL_SSF 64bit bugfix or workaround
by rein＠basefarm.no 07 Mar '08

07 Mar '08

Full_Name: Rein Tollevik Version: 2.4.8 OS: Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.93.160.250) Below is a patch that fixes, or more correctly works around, a 64bit bug in servers/slapd/syncrepl.c that causes a bus error on (at least) 64bit Solaris. The real problem is imho that libraries/libldap/cyrus.c expects the argument where it should write the LDAP_OPT_X_SASL_* options to be of type ber_len_t and not the sasl_*_t type matching the option value it returns. I.e, the pointer variable where the returns values are written should be cast to the appropriate sasl_*_t type, not a ber_len_t. Writing to a 64bit ber_len_t when the argument is a 32bit sasl_ssf_t causes an alignment error at best case, memory corruption at worst. I haven't looked too deeply into other cases where LDAP_OPT_X_SASL_* options are set or retrieved with ldap_set_option() or ldap_get_option(), so I don't know the consequence of changing cyrus.c. That's why I don't have what I would consider a real fix to libraries/libldap/cyrus.c rather than this workaround. Rein Tollevik Basefarm AS Index: servers/slapd/syncrepl.c =================================================================== RCS file: /f/CVSROOT/drift/OpenLDAP/servers/slapd/syncrepl.c,v retrieving revision 1.1.1.18 diff -u -u -w -r1.1.1.18 syncrepl.c --- servers/slapd/syncrepl.c 21 Feb 2008 13:55:21 -0000 1.1.1.18 +++ servers/slapd/syncrepl.c 7 Mar 2008 11:34:08 -0000 @@ -444,6 +444,10 @@ #ifdef HAVE_TLS void *ssl; #endif + ber_len_t ssf; /* XXX The correct type would be sasl_ssf_t, but + * this is what the LDAP_OPT_X_SASL_SSF return + * value is cast into in libldap/cyrus.c + */ rc = slap_client_connect( &si->si_ld, &si->si_bindconf ); if ( rc != LDAP_SUCCESS ) { @@ -462,7 +466,8 @@ op->o_tls_ssf = ldap_pvt_tls_get_strength( ssl ); } #endif /* HAVE_TLS */ - ldap_get_option( si->si_ld, LDAP_OPT_X_SASL_SSF, &op->o_sasl_ssf ); + ldap_get_option( si->si_ld, LDAP_OPT_X_SASL_SSF, &ssf); + op->o_sasl_ssf = ssf; op->o_ssf = ( op->o_sasl_ssf > op->o_tls_ssf ) ? op->o_sasl_ssf : op->o_tls_ssf;

1 0

Re: (ITS#5402) Sets: Hyphens within attribute names considered as separate tokens
by ando＠sys-net.it 06 Mar '08

06 Mar '08

norbert(a)rittel.de wrote: > When using attribute names containing hyphens the Set code erroneously considers > the parts to either side of the hyphen as separate tokens. > > For example a <by> clause like > > by set.exact="this/apple-keyword & user/apple-keyword" read > > always yields an empty set. This means that on Apple Open Directory servers set > clauses canot be used with any Apple-supplied attribute as they all begin with > "apple-". The code that parses attribute descriptions appears to be definitely broken, since it does allow underscores but no hyphens, and it does not allow digits in attribute descriptions (including OIDs). This should be fixed now in HEAD, and the patch servers/slapd/sets.c 1.41 -> 1.42 seems to apply to current re24 and re23 without much hassle. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5402) Sets: Hyphens within attribute names considered as separate tokens
by norbert＠rittel.de 06 Mar '08

06 Mar '08

Full_Name: Norbert Rittel Version: 2.3.27 OS: Mac OS X Server 10.5.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.91.71.78) When using attribute names containing hyphens the Set code erroneously considers the parts to either side of the hyphen as separate tokens. For example a <by> clause like by set.exact="this/apple-keyword & user/apple-keyword" read always yields an empty set. This means that on Apple Open Directory servers set clauses canot be used with any Apple-supplied attribute as they all begin with "apple-". Pierangelo Masarati was so kind to verify that this bug is still present in the latest release. Hopefully the fix is a simple diff that we can apply to the older version shipping with Mac OS X Server, too. :-)

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