- openldap-bugs - openldap.org

Re: (ITS#5182) test048 in OPENLDAP_REL_ENG_2_4
by ando＠sys-net.it 10 Oct '07

10 Oct '07

ghenry(a)OpenLDAP.org wrote: > > "master and R1 slave databases differ" > > I'd like to learn how to debug this. Any tips? > > This is on a 64-Bit AMD machine, 2GB Ram, Berkeley 4.2.52. Can't look at your tar right now; but: - check in scripts/test048* where the "master and R1 slave databases differ" line is, and see what files are being tested - they probably are macros, defined in scripts/defines.sh, something like testrun/ldif.flt and testrun/ldapsearch.flt - run diff -iu FILE1 FILE2 as resolved above and see where it fails. If it points you somewhere (e.g. the difference is trivial, or there's something very specific to a precise modification) fine, otherwise post the outcome. 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#5182) test048 in OPENLDAP_REL_ENG_2_4
by ghenry＠OpenLDAP.org 10 Oct '07

10 Oct '07

Full_Name: Gavin Henry Version: OPENLDAP_REL_ENG_2_4 OS: Fedora 7 URL: http://www.suretec.org/our_docs/test048.tar.gz Submission from: (NULL) (80.229.93.1) Submitted by: ghenry I'm getting a fail at: "master and R1 slave databases differ" I'd like to learn how to debug this. Any tips? This is on a 64-Bit AMD machine, 2GB Ram, Berkeley 4.2.52. Thanks.

1 0

Re: (ITS#5172) slash in dn
by raphael.ouazana＠linagora.com 10 Oct '07

10 Oct '07

Le Mer 10 octobre 2007 02:31, reinhold.may(a)gmx.de a écrit : > adding new entry "cn=With/Slash,ou=My address book,dc=somedomain,dc=org" > ldap_add: No such object (32) > additional info: Parent does not exist > > which is erroneous. My new crystal ball tells me that you are not saying the essential part of the problem: you are using back-ldif, isn't it ? Regards, Raphael Ouazana.

1 0

Re: (ITS#5180) OpenLDAP Website Home Page
by ghenry＠OpenLDAP.org 10 Oct '07

10 Oct '07

>> >> We need a better title ;-) >> >> <TITLE>OpenLDAP, Title</TITLE> >> >> Gavin. >> >> >> > Oh, I've just checked. That's still not great. How about: <TITLE>OpenLDAP - community developed LDAP software</TITLE> -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: (ITS#5180) OpenLDAP Website Home Page
by ghenry＠OpenLDAP.org 10 Oct '07

10 Oct '07

Kurt Zeilenga wrote: > Fixed. Many thanks. > > On Oct 9, 2007, at 7:41 PM, ghenry(a)OpenLDAP.org wrote: > >> Full_Name: Gavin Henry >> Version: >> OS: >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (212.159.59.85) >> Submitted by: ghenry >> >> >> We need a better title ;-) >> >> <TITLE>OpenLDAP, Title</TITLE> >> >> Gavin. >> >> >> > -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: (ITS#5172) slash in dn
by ando＠sys-net.it 10 Oct '07

10 Oct '07

reinhold.may(a)gmx.de wrote: > Pierangelo, > > First of all: Sorry, I've left in fact a paragraph in my .ldif example > that should have come out. > > I can reproduce what you've said and using the following code: > > #include <ldap.h> > #include <stdio.h> > > int main() { > char **c = ldap_explode_dn( > "cn=With/Slash,ou=My address book,dc=somedomain,dc=org", > 1); > > int i; > for (i = 0; c[i] != 0; i++) { > printf("%s\n", c[i]); > } > > return 0; > } > > which correctly produces: > > cn=With/Slash > ou=My address book > dc=somedomain > dc=org > > And executing: > > # slapdn "cn=With/Slash,ou=My address book,dc=somedomain,dc=org" > > produces the expected: > > DN: <cn=With/Slash,ou=My address book,dc=somedomain,dc=org> check succeeded > normalized: <cn=with/slash,ou=my address book,dc=somedomain,dc=org> > pretty: <cn=With/Slash,ou=My address book,dc=somedomain,dc=org> > > However, running the actual example produces the following full output: > > $ ldapadd -x -D 'cn=root,dc=somedomain,dc=org' -W -f test.ldif > Enter LDAP Password: > adding new entry "dc=somedomain,dc=org" > > adding new entry "ou=My address book,dc=somedomain,dc=org" > > adding new entry "cn=With/Slash,ou=My address book,dc=somedomain,dc=org" > ldap_add: No such object (32) > additional info: Parent does not exist > > which is erroneous. > > Just to check that it is the forward slash that must be to blame, here's > the full output of the counter check: > > $ ldapadd -x -D 'cn=root,dc=somedomain,dc=org' -W -f test2.ldif > Enter LDAP Password: > adding new entry "dc=somedomain,dc=org" > > adding new entry "ou=My address book,dc=somedomain,dc=org" > > adding new entry "cn=WithoutSlash,ou=My address book,dc=somedomain,dc=org" > > So, I still suspect a bug... This output is not useful. First of all, can you tell what ldapadd you're using? Please make sure you run the version of ldapadd that comes with OpenLDAP sources you built. Second, please provide an indication of what happens at the server side. Logs at "stats,trace" would be helpful. I can confirm that I can successfully add an entry whose RDN contains a slash "/" to OpenLDAP 2.3. 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

Re: (ITS#5172) slash in dn
by reinhold.may＠gmx.de 09 Oct '07

09 Oct '07

Pierangelo, First of all: Sorry, I've left in fact a paragraph in my .ldif example that should have come out. I can reproduce what you've said and using the following code: #include <ldap.h> #include <stdio.h> int main() { char **c = ldap_explode_dn( "cn=With/Slash,ou=My address book,dc=somedomain,dc=org", 1); int i; for (i = 0; c[i] != 0; i++) { printf("%s\n", c[i]); } return 0; } which correctly produces: cn=With/Slash ou=My address book dc=somedomain dc=org And executing: # slapdn "cn=With/Slash,ou=My address book,dc=somedomain,dc=org" produces the expected: DN: <cn=With/Slash,ou=My address book,dc=somedomain,dc=org> check succeeded normalized: <cn=with/slash,ou=my address book,dc=somedomain,dc=org> pretty: <cn=With/Slash,ou=My address book,dc=somedomain,dc=org> However, running the actual example produces the following full output: $ ldapadd -x -D 'cn=root,dc=somedomain,dc=org' -W -f test.ldif Enter LDAP Password: adding new entry "dc=somedomain,dc=org" adding new entry "ou=My address book,dc=somedomain,dc=org" adding new entry "cn=With/Slash,ou=My address book,dc=somedomain,dc=org" ldap_add: No such object (32) additional info: Parent does not exist which is erroneous. Just to check that it is the forward slash that must be to blame, here's the full output of the counter check: $ ldapadd -x -D 'cn=root,dc=somedomain,dc=org' -W -f test2.ldif Enter LDAP Password: adding new entry "dc=somedomain,dc=org" adding new entry "ou=My address book,dc=somedomain,dc=org" adding new entry "cn=WithoutSlash,ou=My address book,dc=somedomain,dc=org" So, I still suspect a bug... Reinhold

1 0

Re: (ITS#5180) OpenLDAP Website Home Page
by kurt＠OpenLDAP.org 09 Oct '07

09 Oct '07

Fixed. On Oct 9, 2007, at 7:41 PM, ghenry(a)OpenLDAP.org wrote: > Full_Name: Gavin Henry > Version: > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.159.59.85) > Submitted by: ghenry > > > We need a better title ;-) > > <TITLE>OpenLDAP, Title</TITLE> > > Gavin. > > >

1 0

(ITS#5181) ITS Copyright
by ghenry＠OpenLDAP.org 09 Oct '07

09 Oct '07

Full_Name: Gavin Henry Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry Copyright on ITS website page and ITS auto-replies is still at 2006: "Copyright 1998-2006 The OpenLDAP Foundation, All Rights Reserved."

1 0

(ITS#5180) OpenLDAP Website Home Page
by ghenry＠OpenLDAP.org 09 Oct '07

09 Oct '07

Full_Name: Gavin Henry Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry We need a better title ;-) <TITLE>OpenLDAP, Title</TITLE> Gavin.

1 0

(ITS#5179) Weekly generation of Admin Guide for Website
by ghenry＠OpenLDAP.org 09 Oct '07

09 Oct '07

Full_Name: Gavin Henry Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry Dear all, Not sure if I already requested this (can't find the ITS), but can we set up something to do a weekly doc generation for http://www.openldap.org/devel/admin/ Thanks.

1 0

Re: (ITS#4860) Sets' enhancement
by ghenry＠OpenLDAP.org 09 Oct '07

09 Oct '07

ando(a)sys-net.it wrote: >> Howard Chu a écrit : > >> Unfortunately, it's currently heavily dependant on one of our customer's >> specific schema extensions and data tree structure. The ACLs in use >> implement a lot of the logic specific to their environment, therefore I >> can't send them as is. >> >> However, I will see if I can "translate" some of the more complicated >> ACLs (with sets) to perform on a simple data set for inclusion in the >> test suite. >> >> Could some examples such as these also fit your documentation request >> for sets and their applications [1]? Assuming this is the case, I will >> try and provide at least a subset of our test set soon. >> >> Cheers, >> Jon >> >> [1] http://www.openldap.org/lists/openldap-software/200709/msg00310.html > > Let me state first that right now I believe sets do not belong to > slapd(8); they should rather move into a module, under the dynacl > umbrella. And, as such, they should be documented separately from > slapd.access(5), mostly because having them in slapd.access(5) would sort > of encourage unexperienced people into (ab-)using them. > > Also, I'd like sets' users to document them (especially in terms of useful > hints, scenarios, case studies and so), as they probably best know what > one can gain from their use. Otherwise, a bare description of the syntax, > although necessary, would hardly be useful to most of the users. > > p. > Agreed. Once decided, we can discuss where they would fit in the Admin guide. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: (ITS#5176) Segmentation Fault in test001-slapadd
by ando＠sys-net.it 09 Oct '07

09 Oct '07

> Full_Name: Mark > Version: 2.3.38 > OS: Suse Linux 10.01 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.128.87.178) > > > ** Problem > test001-slapdadd fails with segmentation fault. > > ** Environment > Suse Linux 10.1 > Berkly DB 4.6.21 > Openldap 2.3.38 OpenLDAP 2.3 does not support Berkeley > 4.6.9; this issue has been risen dozens of times, but apprently browsing archives for known issues has become unfashionable. Please either upgrade to OpenLDAP 2.4 or downgrade to Berkeley < 4.6. This ITS will be closed. 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#5178) [feature request] pcache stats & monitoring
by ando＠sys-net.it 09 Oct '07

09 Oct '07

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.203.230.29) Submitted by: ando This is a feature request for stats and monitoring capabilities for pcache; basically: - the number of cached queries - the number of cached entries - possibly, a list of cached queries in cachedQueryURL form - how many times each cached query was used instead of re-running the request - the ratio answerable / cacheable for each cacheable query - some global figure like the average response time (send searchResult time - start caching time) for each query, and the overall average. Adding per-query info could be done by either extending the cachedQueryURL format or by adding a child entry for each cached query (like connections and other dynamic info). p.

1 0

Re: (ITS#4860) Sets' enhancement
by ando＠sys-net.it 09 Oct '07

09 Oct '07

> Howard Chu a écrit : > Unfortunately, it's currently heavily dependant on one of our customer's > specific schema extensions and data tree structure. The ACLs in use > implement a lot of the logic specific to their environment, therefore I > can't send them as is. > > However, I will see if I can "translate" some of the more complicated > ACLs (with sets) to perform on a simple data set for inclusion in the > test suite. > > Could some examples such as these also fit your documentation request > for sets and their applications [1]? Assuming this is the case, I will > try and provide at least a subset of our test set soon. > > Cheers, > Jon > > [1] http://www.openldap.org/lists/openldap-software/200709/msg00310.html Let me state first that right now I believe sets do not belong to slapd(8); they should rather move into a module, under the dynacl umbrella. And, as such, they should be documented separately from slapd.access(5), mostly because having them in slapd.access(5) would sort of encourage unexperienced people into (ab-)using them. Also, I'd like sets' users to document them (especially in terms of useful hints, scenarios, case studies and so), as they probably best know what one can gain from their use. Otherwise, a bare description of the syntax, although necessary, would hardly be useful to most of the users. 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

Re: (ITS#4860) Sets' enhancement
by hyc＠symas.com 09 Oct '07

09 Oct '07

jclarke(a)linagora.com wrote: > However, I will see if I can "translate" some of the more complicated > ACLs (with sets) to perform on a simple data set for inclusion in the > test suite. > > Could some examples such as these also fit your documentation request > for sets and their applications [1]? Assuming this is the case, I will > try and provide at least a subset of our test set soon. Absolutely. Thanks... > > Cheers, > Jon > > [1] http://www.openldap.org/lists/openldap-software/200709/msg00310.html -- -- 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#4860) Sets' enhancement
by jclarke＠linagora.com 09 Oct '07

09 Oct '07

Howard Chu a écrit : > jclarke(a)linagora.com wrote: >> Got this one: it was a double-free in sets.c occuring after a >> slap_set_join() with lset or rset empty - the non empty set was >> returned, and then freed, causing a double-free error or segfault. >> >> The patch attached corrects this problem on RE23 and HEAD for me and >> doesn't have any side effects on our test set. However, it may not be >> the "right" way - please correct if necessary! > > Is your test set something you can clean up for inclusion in our test > suite? Unfortunately, it's currently heavily dependant on one of our customer's specific schema extensions and data tree structure. The ACLs in use implement a lot of the logic specific to their environment, therefore I can't send them as is. However, I will see if I can "translate" some of the more complicated ACLs (with sets) to perform on a simple data set for inclusion in the test suite. Could some examples such as these also fit your documentation request for sets and their applications [1]? Assuming this is the case, I will try and provide at least a subset of our test set soon. Cheers, Jon [1] http://www.openldap.org/lists/openldap-software/200709/msg00310.html -- Jonathan Clarke Cellule OSSA - Groupe LINAGORA 27 rue de Berri, 75008 Paris Tél: 01 58 18 68 28, fax: 01 58 18 68 29 http://www.linagora.com - http://www.08000linux.com

1 0

Re: (ITS#4860) Sets' enhancement
by ando＠sys-net.it 09 Oct '07

09 Oct '07

> jclarke(a)linagora.com a écrit : >> Pierangelo Masarati a écrit : >>> Should be fixed now in HEAD/re24/re23. Please test. p. >> >> I've been testing (at last, sorry for the delay), and I've come across >> another memory problem. Backtrace is below, and valgrind output is >> attached. > > Got this one: it was a double-free in sets.c occuring after a > slap_set_join() with lset or rset empty - the non empty set was > returned, and then freed, causing a double-free error or segfault. > > The patch attached corrects this problem on RE23 and HEAD for me and > doesn't have any side effects on our test set. However, it may not be > the "right" way - please correct if necessary! Thanks for spotting it - I had no time to look at your last report. I'll check the fix and eventually apply it. > Your recent fixes have solved all the issues from our test cases we were > encountering. Thank you very much for them. Sure. Cheers, 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

Re: (ITS#4860) Sets' enhancement
by hyc＠symas.com 09 Oct '07

09 Oct '07

jclarke(a)linagora.com wrote: > Got this one: it was a double-free in sets.c occuring after a > slap_set_join() with lset or rset empty - the non empty set was > returned, and then freed, causing a double-free error or segfault. > > The patch attached corrects this problem on RE23 and HEAD for me and > doesn't have any side effects on our test set. However, it may not be > the "right" way - please correct if necessary! Is your test set something you can clean up for inclusion in our test suite? > Your recent fixes have solved all the issues from our test cases we were > encountering. Thank you very much for them. > > Jon -- -- 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#4860) Sets' enhancement
by jclarke＠linagora.com 09 Oct '07

09 Oct '07

This is a multi-part message in MIME format. --------------080102080503050601010703 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit jclarke(a)linagora.com a écrit : > Pierangelo Masarati a écrit : >> Should be fixed now in HEAD/re24/re23. Please test. p. > > I've been testing (at last, sorry for the delay), and I've come across > another memory problem. Backtrace is below, and valgrind output is attached. Got this one: it was a double-free in sets.c occuring after a slap_set_join() with lset or rset empty - the non empty set was returned, and then freed, causing a double-free error or segfault. The patch attached corrects this problem on RE23 and HEAD for me and doesn't have any side effects on our test set. However, it may not be the "right" way - please correct if necessary! Your recent fixes have solved all the issues from our test cases we were encountering. Thank you very much for them. Jon -- Jonathan Clarke Cellule OSSA - Groupe LINAGORA 27 rue de Berri, 75008 Paris Tél: 01 58 18 68 28, fax: 01 58 18 68 29 http://www.linagora.com - http://www.08000linux.com --------------080102080503050601010703 Content-Type: text/x-patch; name="jonathan-clarke-071008.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="jonathan-clarke-071008.patch" --- servers/slapd/sets.c.orig 2007-10-08 18:20:08.000000000 +0200 +++ servers/slapd/sets.c 2007-10-08 18:22:29.000000000 +0200 @@ -261,11 +261,15 @@ } else { set = set_dup( cp, lset, SLAP_SET_LREF2REF( op_flags ) ); + /* set array reference has been copied - don't free */ + op_flags |= SLAP_SET_LREFVAL | SLAP_SET_LREFARR; break; } } else if ( j == 0 ) { set = set_dup( cp, rset, SLAP_SET_RREF2REF( op_flags ) ); + /* set array reference has been copied - don't free */ + op_flags |= SLAP_SET_RREFVAL | SLAP_SET_RREFARR; break; } --------------080102080503050601010703--

1 0

Re: (ITS#4940) libldap doesn't wait for server's TLS close_notify
by hyc＠symas.com 09 Oct '07

09 Oct '07

Philip Guenther wrote: > Anyway, this issue isn't worth keep an ITS open about, as it doesn't > actually cause failures or visible errors. I might someday chase down a > clean way of implementing this second option, but only after the much more > useful work of coming up with a reasonable API to let event-driven apps do > STARTTLS without blocking. Someday. Ah yes, Someday. Drop by this page when you get a chance: http://scratchpad.wikia.com/wiki/LDAP_C_API Some day it'll be more than just a single page... -- -- 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#4940) libldap doesn't wait for server's TLS close_notify
by guenther+ldapdev＠sendmail.com 09 Oct '07

09 Oct '07

On Mon, 8 Oct 2007, Howard Chu wrote: ... >> There are a number of ways this can be handled: >> 1) change the client to wait until it sees the server's close_notify alert >> by >> replacing "SSL_shutdown( p->ssl );" in tls.c with the two lines: >> if (SSL_shutdown( p->ssl ) == 0) >> SSL_shutdown( p->ssl ); >> (I have confirmed that this works. As documented, the first call >> will return 1 if the server's close_notify has already been >> received, if not, the second call will block until it is received.) > > So if the server doesn't send one, the client will be stuck waiting forever? It would also unblock if the server closed the connection. One downside of this option that I thought of later is that it shifts the TCP CLOSE_WAIT state from the client to the server. Fixing that would add more complexity to the sockbuf layer than this entire change is worth. Having chatted with Kurt about this at the last IETF meeting and pondered failure modes, I'm no longer in favor of this option. >> 2) change the client to not bother to send a close_notify alert when >> it's just going to close() the connection; change the server to not >> send a close_notify if it didn't get one. <...> > > Sounds like a change in the SSL library, not something for us to worry > about. Since "send a close_notify alert" == "call SSL_shutdown() for the first time", it would be a change in how the SSL library was used by libldap. Anyway, this issue isn't worth keep an ITS open about, as it doesn't actually cause failures or visible errors. I might someday chase down a clean way of implementing this second option, but only after the much more useful work of coming up with a reasonable API to let event-driven apps do STARTTLS without blocking. Someday. Philip Guenther

1 0

Re: ITS#5174 openldap.schema entry not valid per RFC 4512
by ando＠sys-net.it 09 Oct '07

09 Oct '07

> The reason I reported it was that I wrote a parser for LDAP schema > based directly on the formal grammar, downloaded all the schema from > OpenLDAP as a test, and that was the only schema that broke, and only > on the one element. I did not have any trouble with the OpenLDAP > software accepting the schema. If you use a grammar builder (I used > ANTLR) rather than a hand-coded parser, being permissive makes it a > bit more complex. Allowing the elements to appear in any order would > be easy to parse for the RFC 4512 elements, because they happen to be > defined with markers ("NAME", "DESC" and so on) that makes them easy > to differentiate, but then enforcing at-most-once semantics on the > elements requires either an additional pass or some hand coded > predicates to check for duplicates in a data structure being built on- > the-fly. Thanks for the feedback. It's now fixed in HEAD/re24. 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

Re: ITS#5174 openldap.schema entry not valid per RFC 4512
by bhanafee＠gmail.com 08 Oct '07

08 Oct '07

p., Thanks for looking at it. I think the RFC 4234 parse of the elements in the RFC 4512 definition would be as a 'concatenation' (based on rule->elements->alternation->concatenation). To get "any order" behavior under RFC 4234, I think the elements in the definition would be separated by '/' characters, and all the elements would be enclosed in a group with a repetition element. There's an example in the "Generalized Time" definition (RFC 4517, section 3.3.13) that shows why the optional members must be in sequence by default. In that particular case, the [fraction] can't be allowed to appear before the [minute ...] part, or it would be ambiguous whether the final "3015" in "2007100807.53015" was part of the fraction or a minute and second that appears (for no good reason) after the fraction ".5" The reason I reported it was that I wrote a parser for LDAP schema based directly on the formal grammar downloaded all the schema from OpenLDAP as a test. That was the only schema that broke, and only on the one element. I did not have any trouble with the OpenLDAP software accepting the schema. If you use a grammar builder (I used ANTLR) rather than a hand-coded parser, being permissive makes it a bit more complex. Allowing the elements to appear in any order would be easy to parse for the RFC 4512 elements, because they happen to be defined with markers ("NAME", "DESC" and so on) that makes them easy to differentiate, but then enforcing at-most-once semantics on the elements requires either an additional pass or some hand coded predicates to check for duplicates in a data structure being built on-the-fly. -- Brian On 10/8/07, Pierangelo Masarati <ando(a)sys-net.it> wrote: > Not sure if ordering of optional sequence members is required by RFC > 4234, but the change you suggest sounds harmless. OpenLDAP software, in > this sense, is usually permissive in what is accepted and strict in what > is emitted. > > Thanks, 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

Re: (ITS#4940) libldap doesn't wait for server's TLS close_notify
by hyc＠symas.com 08 Oct '07

08 Oct '07

guenther+ldapdev(a)sendmail.com wrote: > Full_Name: Philip Guenther > Version: 2.3.27 > OS: Linux and Solaris > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (64.58.1.252) > > > [I vaguely recall seeing a report of this issue in the archives of one of the > mailing lists, but I can no longer find the original.] > > If you trace the packets sent when you use, for example, ldapsearch against a > server on a different host, using either the -Z option to do TLS or using an > ldaps URI, you'll discover that the TCP connection is actually reset instead of > being closed cleanly: the client sends TCP RSTs in response to the server's > final packets. > > This is because libldap uses the following sequence when unbind a TLS or SSL > connection: > 1) send the unbind request (over the TLS or SSL layer) > 2) call SSL_shutdown(), sending the TLS close_notify alert > 3) call close() > > After receiving the close_notify alert from step (2), the server sends back its > own close_notify alert and then calls close(). However, because the client > didn't wait for the server's response before calling close() on its end, the > client's TCP stack considers the TCP connection to already be gone and responds > with the RST packets. This occurs with Linux and Solaris clients and probably > most other unices: the response to packets after a close() doesn't vary in my > experience. > > There are a number of ways this can be handled: > 1) change the client to wait until it sees the server's close_notify alert by > replacing "SSL_shutdown( p->ssl );" in tls.c with the two lines: > if (SSL_shutdown( p->ssl ) == 0) > SSL_shutdown( p->ssl ); > (I have confirmed that this works. As documented, the first call will return > 1 > if the server's close_notify has already been received, if not, the second > call > will block until it is received.) So if the server doesn't send one, the client will be stuck waiting forever? > 2) change the client to not bother to send a close_notify alert when it's just > going to close() the connection; change the server to not send a > close_notify > if it didn't get one. This probably violates the TLS spec, but the fact > that > TLS/1.1 permits resumption of sessions without close_notify having been sent > indicates that the violation is not a major issue, particularly given that > LDAP's > unbind request prevents truncation attacks. Close_notifies are, of course, > required if the client just wants to terminate the TLS layer and resume > unprotected LDAP operations. Sounds like a change in the SSL library, not something for us to worry about. > > 3) ignore the issue: it only causes one or two extra packets to be sent. While > it > also eliminates the TIME_WAIT state, LDAP's application-level close (the > unbind > request) means it doesn't need reliable full-duplex closure, so the only > concern > would be random connection issues from reincarnations of the TCP tuple, > which > is unlikely for an LDAP connection. > Personally, I like the simplicity and cleanliness of solution (1). (1) has the possibility of an indefinite hang. As such, I think it best to leave it with the current behavior. -- -- 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs