- openldap-bugs - openldap.org

Re: (ITS#5825) syncrepl default is no retry
by hyc＠symas.com 22 Nov '08

22 Nov '08

ando(a)sys-net.it wrote: > Full_Name: Pierangelo Masarati > Version: irrelevant > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.63.140.131) > Submitted by: ando > > > Syncrepl by default uses no retry. This is extremely useless, as syncrepl with > no retry will probably break, sooner or later, without notifying why it > happened. Legacy behavior, since retry was added later... > I believe it would be safe to have either: > > - a "safe" retry value (not too often, e.g. every hour, forever) Sounds fine, just add it to the doc. > - a warning (or an error) if retry is not given when configuring syncrepl Sounds rather annoying. We could combine these: if no retry was configured, give the warning and use a default of 1 hour. Have to ensure that the default setting doesn't persist in cn=config, so that it will keep warning until an explicit value is set. > Another interesting feature would be to register syncrepl-specific parameters in > back-monitor's entry of each database, that > - show the status of syncrepl (whether it's up, if rp) > > - show the timestamp of the last successful refresh > > - show the timestamp of the last failed attempt, and the reason of the failure Sounds fine, but unless you can add these quickly I don't see any reason to hold 2.4.13 for it. -- -- 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#5826) syncrepl leaking filter in MMR
by ando＠sys-net.it 22 Nov '08

22 Nov '08

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando The filterstring is not freed if generated. A fix is coming. p.

1 0

(ITS#5825) syncrepl default is no retry
by ando＠sys-net.it 22 Nov '08

22 Nov '08

Full_Name: Pierangelo Masarati Version: irrelevant OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando Syncrepl by default uses no retry. This is extremely useless, as syncrepl with no retry will probably break, sooner or later, without notifying why it happened. I believe it would be safe to have either: - a "safe" retry value (not too often, e.g. every hour, forever) - a warning (or an error) if retry is not given when configuring syncrepl Another interesting feature would be to register syncrepl-specific parameters in back-monitor's entry of each database, that - show the status of syncrepl (whether it's up, if rp) - show the timestamp of the last successful refresh - show the timestamp of the last failed attempt, and the reason of the failure p.

1 0

ldap_domain2hostlist is for "ldap" service only
by Marc Lavergne 22 Nov '08

22 Nov '08

Have there been any considerations in providing a similar API for a service name other than "ldap"? For example, what if I wanted to find global catalog servers? Even though GCs are Active Directory specific, I don't see why OpenLDAP would not support that type of query. It seems like a new API where the service name can be passed in as a parameter (eg. "gc") would be useful. Before using ITS to issue a bug report, I thought I'd ask via this forum. Thanks.

4 4

Re: (ITS#5821) Small mistake in man page
by ando＠sys-net.it 22 Nov '08

22 Nov '08

andrew.findlay(a)skills-1st.co.uk wrote: > On Thu, Nov 20, 2008 at 02:43:22PM +0000, kkalev(a)gmail.com wrote: > >> In the manpage for slapd.conf (slapd.conf.5) in the limits directive description >> the value for the size.unchecked pattern should be disabled and not disable >> according to limits.c > > Well spotted! > > I am curious about why this feature was added. The man page says: > > If it is set to disable, the search is not even performed; this > can be used to disallow searches for a specific set of users. > > Disallowing searches seems more like an ACL job than a limit job > to me, so I did not mention this when writing up the Limits features > for the Admin Guide. > > Does anyone actually use unchecked=disabled and if so, why? ACLs act too late, after the search has been performed; this acts at the candidate selection level, and with similar granularity in terms of identity the request is performed as. Now, search access to the searchBase is checked, so a search can be stopped even earlier. This was not requested when this limits feature was introduced. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5821) Small mistake in man page
by andrew.findlay＠skills-1st.co.uk 21 Nov '08

21 Nov '08

On Thu, Nov 20, 2008 at 02:43:22PM +0000, kkalev(a)gmail.com wrote: > In the manpage for slapd.conf (slapd.conf.5) in the limits directive description > the value for the size.unchecked pattern should be disabled and not disable > according to limits.c Well spotted! I am curious about why this feature was added. The man page says: If it is set to disable, the search is not even performed; this can be used to disallow searches for a specific set of users. Disallowing searches seems more like an ACL job than a limit job to me, so I did not mention this when writing up the Limits features for the Admin Guide. Does anyone actually use unchecked=disabled and if so, why? Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

Re: (ITS#5823) clients/tools don't honor ldap.conf defaults
by hyc＠symas.com 21 Nov '08

21 Nov '08

h.b.furuseth(a)usit.uio.no wrote: > Pierangelo Masarati writes: >> -ZZ should be deprecated, and -Z should simply and strictly require >> StartTLS. > > Good point. Except then people who are used to new clients will > make insecure connections when using old clients. Maybe -Z should > be an error instead... > > What I'd really really like to do is throw away all the options, > rename the programs, and start over. This time with the same option > names in ldap tools, slap tools, and slapd itself. Goes with the > someday-in-the-future library rewrite, I suppose. OpenLDAP 3.0... The question is, when do we stop the 2.x stream and begin 3.0? -- -- 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#5822 slapd goes into sleeping mode
by h.b.furuseth＠usit.uio.no 21 Nov '08

21 Nov '08

egarciab(a)alcatel-lucent.com writes: > Did you see anytime a similar problem of slapd sleeping mode? Slapd does not have a "sleeping mode", but there have been bugs with the locking code. E.g. a function takes a lock but in the case of some rare error return it forgets to release it. Then the next attempt to use that resource (e.g. a locked entry, or a locked database) will hang. I see you use "database oci". This was never part of OpenLDAP as far as I know. <google oci site:openldap.org> shows the code was submitted. I don't know the slapd SQL code and haven't checked if the code was rejected because of some problem, or merged into back-sql, or something else. If you browse these messages, maybe that'll turn up your problem. -- Hallvard

1 0

Re: (ITS#5823) clients/tools don't honor ldap.conf defaults
by ando＠sys-net.it 21 Nov '08

21 Nov '08

h.b.furuseth(a)usit.uio.no wrote: > Pierangelo Masarati writes: >> -ZZ should be deprecated, and -Z should simply and strictly require >> StartTLS. > > Good point. Except then people who are used to new clients will > make insecure connections when using old clients. Maybe -Z should > be an error instead... Mine was a generic criticism, not a suggestion for this specific case. > What I'd really really like to do is throw away all the options, > rename the programs, and start over. This time with the same option > names in ldap tools, slap tools, and slapd itself. Goes with the > someday-in-the-future library rewrite, I suppose. :) 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5823) clients/tools don't honor ldap.conf defaults
by h.b.furuseth＠usit.uio.no 21 Nov '08

21 Nov '08

Pierangelo Masarati writes: > -ZZ should be deprecated, and -Z should simply and strictly require > StartTLS. Good point. Except then people who are used to new clients will make insecure connections when using old clients. Maybe -Z should be an error instead... What I'd really really like to do is throw away all the options, rename the programs, and start over. This time with the same option names in ldap tools, slap tools, and slapd itself. Goes with the someday-in-the-future library rewrite, I suppose. -- Hallvard

1 0

Re: ITS#5822 slapd goes into sleeping mode
by ando＠sys-net.it 21 Nov '08

21 Nov '08

GARCIA BARRERA, Eduardo (Eduardo) wrote: > Ok, I can fully understand your point. > > Anyway, from your expert point of view on openldap, and understanding > that this is an obsolete version of slapd, I would like only two things > that you probably know without consuming much time from your side. It's not a matter of consuming my time. We're all condemned to consume all of our time sooner or later. It's a matter of consuming it on something we consider worth it, and enjoy it in the meanwhile. One of the pleasures of working at free software is that nobody can really tell you what to work at :) > Did you see anytime a similar problem of slapd sleeping mode? Slapd has no "sleeping mode" (would it make any sense?) Do the logs show anything relevant *before* slapd becomes unresponsive? You mentioned that attaching the process with gdb is not an option, since it's operating in a very critical environment. However, I believe you wouldn't make things any worse when it's no longer responding anyway. > Did you think if there is any solaris patches that could fix similar > problems? Not a solaris expert, sorry. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

RE: ITS#5822 slapd goes into sleeping mode
by egarciab＠alcatel-lucent.com 21 Nov '08

21 Nov '08

Ok, I can fully understand your point. Anyway, from your expert point of view on openldap, and understanding that this is an obsolete version of slapd, I would like only two things that you probably know without consuming much time from your side. Did you see anytime a similar problem of slapd sleeping mode? Did you think if there is any solaris patches that could fix similar problems? Thanks a lot for your time and effort Pierlangelo, Eduardo -----Original Message----- From: Pierangelo Masarati [mailto:ando@sys-net.it] Sent: viernes, 21 de noviembre de 2008 12:11 To: GARCIA BARRERA, Eduardo (Eduardo) Cc: openldap-its(a)openldap.org Subject: Re: ITS#5822 slapd goes into sleeping mode GARCIA BARRERA, Eduardo (Eduardo) wrote: > Pierlangelo, > > First of all, thanks for your quick answer. I just read carefully the > instructions on "how to report a bug", and I will try my best to > gather it. > > Anyway, I got a question for you. Since the slapd process does not > crash but keeps in a sleeping mode, and due to this machine is working > in a very critical enviroment for our customer, is it needed to run > gdb tool? > > Besides, the problem happens in a random way, so we could run those > commands when the slapd is sleeping and does not answer. When this > happens, the ldapsearch command is not answered. > > Platform: SunOS MVICBDS01D05 5.9 Generic_118558-35 sun4u sparc > SUNW,Sun-Fire-15000 > > In this machine is also running oracle version 9.2.0.8 . > > > The slapd.conf file is attached to this email. One issue is that you should clarify what version you're using. If you're really using a OpenLDAP 2.1 release, then it's probably not worth the effort of tracing the issue: that release became historic in early 2004. No one will ever spend time finding a bug in it, or even backporting fixes to known bugs (unless very well rewarded, I guess). 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: ITS#5822 slapd goes into sleeping mode
by ando＠sys-net.it 21 Nov '08

21 Nov '08

GARCIA BARRERA, Eduardo (Eduardo) wrote: > Pierlangelo, > > First of all, thanks for your quick answer. I just read carefully the > instructions on "how to report a bug", and I will try my best to gather > it. > > Anyway, I got a question for you. Since the slapd process does not > crash but keeps in a sleeping mode, and due to this machine is working > in a very critical enviroment for our customer, is it needed to run gdb > tool? > > Besides, the problem happens in a random way, so we could run those > commands when the slapd is sleeping and does not answer. When this > happens, the ldapsearch command is not answered. > > Platform: SunOS MVICBDS01D05 5.9 Generic_118558-35 sun4u sparc > SUNW,Sun-Fire-15000 > > In this machine is also running oracle version 9.2.0.8 . > > > The slapd.conf file is attached to this email. One issue is that you should clarify what version you're using. If you're really using a OpenLDAP 2.1 release, then it's probably not worth the effort of tracing the issue: that release became historic in early 2004. No one will ever spend time finding a bug in it, or even backporting fixes to known bugs (unless very well rewarded, I guess). 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

RE: ITS#5822 slapd goes into sleeping mode
by egarciab＠alcatel-lucent.com 21 Nov '08

21 Nov '08

This is a multi-part message in MIME format. ------_=_NextPart_001_01C94BC8.DD31A533 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Pierlangelo, First of all, thanks for your quick answer. I just read carefully the instructions on "how to report a bug", and I will try my best to gather it. Anyway, I got a question for you. Since the slapd process does not crash but keeps in a sleeping mode, and due to this machine is working in a very critical enviroment for our customer, is it needed to run gdb tool?=20 Besides, the problem happens in a random way, so we could run those commands when the slapd is sleeping and does not answer. When this happens, the ldapsearch command is not answered. Platform: SunOS MVICBDS01D05 5.9 Generic_118558-35 sun4u sparc SUNW,Sun-Fire-15000 In this machine is also running oracle version 9.2.0.8 . The slapd.conf file is attached to this email. Thanks a lot in advance Regards Eduardo -----Original Message----- From: Pierangelo Masarati [mailto:ando@sys-net.it]=20 Sent: jueves, 20 de noviembre de 2008 16:57 To: GARCIA BARRERA, Eduardo (Eduardo) Cc: openldap-its(a)openldap.org Subject: Re: ITS#5822 slapd goes into sleeping mode There exists no OpenLDAP 2.1 b102. There exists a 2.1 branch, which was obsoleted few years ago. Even if there existed one, you don't provide enough info that could help debugging your issue. Please see <http://www.openldap.org/faq/data/cache/56.html> for details about how to report an issue. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it ----------------------------------- ------_=_NextPart_001_01C94BC8.DD31A533 Content-Type: application/octet-stream; name="slapd.conf" Content-Transfer-Encoding: base64 Content-Description: slapd.conf Content-Disposition: attachment; filename="slapd.conf" aW5jbHVkZQkJL29wdC9sdWNlbnQzMi9ldGMvb3BlbmxkYXAvc2NoZW1hL2NvcmUuc2NoZW1hCmlu Y2x1ZGUgICAgICAgICAvb3B0L2x1Y2VudDMyL2V0Yy9vcGVubGRhcC9zY2hlbWEvY29zaW5lLnNj aGVtYQppbmNsdWRlCQkvb3B0L2x1Y2VudDMyL2V0Yy9vcGVubGRhcC9zY2hlbWEvaW5ldG9yZ3Bl cnNvbi5zY2hlbWEKCmluY2x1ZGUgICAgICAgICAvb3B0L2x1Y2VudDMyL2V0Yy9vcGVubGRhcC9z Y2hlbWEvc2l1LnNjaGVtYQppbmNsdWRlICAgICAgICAgL29wdC9sdWNlbnQzMi9ldGMvb3Blbmxk YXAvc2NoZW1hL3Nlc2lvbi5zY2hlbWEKI2luY2x1ZGUgICAgICAgIC9vcHQvbHVjZW50MzIvZXRj L29wZW5sZGFwL3NjaGVtYS9zZXNpb25fdW5kZXIuc2NoZW1hCmluY2x1ZGUgICAgICAgICAvb3B0 L2x1Y2VudDMyL2V0Yy9vcGVubGRhcC9zY2hlbWEvb3BlcmF0aXZvcy5zY2hlbWEKCnBpZGZpbGUJ CS9vcHQvbHVjZW50MzIvdmFyL3NsYXBkLnBpZAphcmdzZmlsZQkvb3B0L2x1Y2VudDMyL3Zhci9z bGFwZC5hcmdzCgp0aHJlYWRzIDE2CgojIGZ1bmNpb25hIGVsIGFjY2VzbyBzZSBjb250cm9sYSBw YXJhIHVzdWFyaW9zIGRlIHRpcG8gdWlkPSxvdT0sbz1iZGIKI2FjY2VzcyAJdG8gZG4uc3VidHJl ZT0ibz1iZGIiCiMgICAgICAgIGJ5IGFub255bW91cyBhdXRoCiMgICAgICAgIGJ5IGRuLnN1YnRy ZWU9Im91PXJlYWQsbz1iZGIiIHNlYXJjaAojICAgICAgICBieSBkbi5zdWJ0cmVlPSJvdT13cml0 ZSxvPWJkYiIgd3JpdGUKI2FjY2VzcyAJdG8gZG4uc3VidHJlZT0ibz1vY2kiCiMgICAgICAgIGJ5 IGFub255bW91cyBhdXRoCiMgICAgICAgIGJ5IGRuLnN1YnRyZWU9Im91PXJlYWQsbz1iZGIiIHNl YXJjaAojICAgICAgICBieSBkbi5zdWJ0cmVlPSJvdT13cml0ZSxvPWJkYiIgd3JpdGUKCiMgRXN0 byBmdW5jaW9uYQojYWNjZXNzIHRvIGRuLnN1YnRyZWU9Im89c2l1IgojCWJ5IGFub255bW91cyB3 cml0ZQojCWJ5IGFub255bW91cyByZWFkCgphY2Nlc3MgdG8gZG4uc3VidHJlZT0ibz1zaXUiCgli eSBhbm9ueW1vdXMgcmVhZAoJYnkgZ3JvdXAuYmFzZT0iY249YWRtaW4iIHdyaXRlCglieSAqIG5v bmUKCmFjY2VzcyB0byBkbi5zdWJ0cmVlPSJvPXNpdXgiCglieSBhbm9ueW1vdXMgcmVhZAoJYnkg Z3JvdXAuYmFzZT0iY249YWRtaW4iIHdyaXRlCglieSAqIG5vbmUKCgojIHNlIGNvbnRyb2xhIGVs IGFjY2VzbwojYWNjZXNzIAl0byBkbi5zdWJ0cmVlPSJvPWJkYiIKIyAgICAgICAgYnkgYW5vbnlt b3VzIGF1dGgKIyAgICAgICAgYnkgZG4uc3VidHJlZT0ibz1iZGIiIHdyaXRlCgojICAgICAgICBi eSAqIHNlYXJjaAojICAgICAgICBieSBkbi5zdWJ0cmVlPSJvPWJkYiIgd3JpdGUKCmFsbG93IGJp bmRfdjIKI2Rpc2FsbG93IGJpbmRfYW5vbiwgYmluZF9zaW1wbGVfdW5wcm90ZWN0ZWQKI2Rpc2Fs bG93IGJpbmRfc2ltcGxlCiNkaXNhbGxvdyBiaW5kX2Fub24KCnNpemVsaW1pdCAxMAp0aW1lbGlt aXQgNjAKCiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjCiMgbGRibSBkYXRhYmFzZSBkZWZpbml0aW9ucwojIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIwoKZGF0YWJhc2UJYmRiCnN1ZmZpeAkJIm89YmRiIgpyb290ZG4JCSJjbj1hZG1pbixv PWJkYiIKcm9vdHB3CQlhZG1pbjEyMwojIFRoZSBkYXRhYmFzZSBkaXJlY3RvcnkgTVVTVCBleGlz dCBwcmlvciB0byBydW5uaW5nIHNsYXBkIEFORCAKIyBzaG91bGQgb25seSBiZSBhY2Nlc3NpYmxl IGJ5IHRoZSBzbGFwZCBhbmQgc2xhcCB0b29scy4KIyBNb2RlIDcwMCByZWNvbW1lbmRlZC4KZGly ZWN0b3J5CS9MVUNFTlQvdmFyL29wZW5sZGFwLWRhdGEKIyBJbmRpY2VzIHRvIG1haW50YWluCmlu ZGV4CW9iamVjdENsYXNzCWVxCgojIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwojIG9jaSAgZGF0YWJhc2UgZGVmaW5p dGlvbnMKIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMKZGF0YWJhc2UgICAgICAgIG9jaQpzdWZmaXggICAgICAgICAg Im89c2l1Igpyb290ZG4gICAgICAgICAgImNuPWFkbWluLCBvPXNpdSIKcm9vdHB3ICAgICAgICAg IGFkbWluMTIzCmRiaG9zdCAgICAgICAgICBtdmljYmRzMDFkMDVfbmF2aXMKZGJuYW1lICAgICAg ICAgIG5hdmlzMTEKZGJ1c2VyICAgICAgICAgIGxkYXAKZGJwYXNzd2QgICAgICAgIGxkYXAxMjMK Y21pbgkJMQpjbWF4CQkxMAogCmRhdGFiYXNlICAgICAgICBvY2kKc3VmZml4ICAgICAgICAgICJv PXNpdXgiCnJvb3RkbiAgICAgICAgICAiY249YWRtaW4sIG89c2l1eCIKcm9vdHB3ICAgICAgICAg IGFkbWluMTIzCmRiaG9zdCAgICAgICAgICBtdmljYmRzMDFkMDVfbmF2aXMKZGJuYW1lICAgICAg ICAgIG5hdmlzMTEKZGJ1c2VyICAgICAgICAgIGxkYXAKZGJwYXNzd2QgICAgICAgIGxkYXAxMjMK Y21pbgkJMQpjbWF4CQkxMAoKI2RhdGFiYXNlICAgICAgICBvY2kKI3N1ZmZpeCAgICAgICAgICAi bz1zaXUiCiNyb290ZG4gICAgICAgICAgImNuPWFkbWluLCBvPXNpdSIKI3Jvb3RwdyAgICAgICAg ICBhZG1pbjEyMwojZGJob3N0ICAgICAgICAgIGNodWVjYQojZGJuYW1lICAgICAgICAgIHNpdQoj ZGJ1c2VyICAgICAgICAgIGFhYQojZGJwYXNzd2QgICAgICAgIGFhYTEyMwojY21pbgkJMQojY21h eAkJNAogCg== ------_=_NextPart_001_01C94BC8.DD31A533--

1 0

Re: (ITS#5823) clients/tools don't honor ldap.conf defaults
by ando＠sys-net.it 20 Nov '08

20 Nov '08

h.b.furuseth(a)usit.uio.no wrote: > hyc(a)OpenLDAP.org writes: >> I suggest that we use option==1 for on, and option>1 for off, to >> minimize the impact of the change. (E.g., to explicitly turn off >> referrals, use ldapsearch -CC.) > > That conflicts with today's -ZZ, which seems a bad option to > create confusion about. -ZZ should be deprecated, and -Z should simply and strictly require StartTLS. The concept itself of having StartTLS optional (without notice of whether it succeeded or not!) sounds extremely bogus to me. In all the clients I develop, I never provide such alternative, either on or off. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5824) #if/#elif issues in thread #includes
by h.b.furuseth＠usit.uio.no 20 Nov '08

20 Nov '08

Full_Name: Hallvard B Furuseth Version: HEAD, RE24 OS: Linux URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard This ldap_pvt_thread.h snippet is invalid: #define LDAP_PVT_THREAD_STACK_SIZE ( 1 * 1024 * 1024 * sizeof(void *) ) #elif LDAP_PVT_THREAD_STACK_SIZE == 0 The standard is worded so that the #elif expression is evaluated even when the preceding #if was true - so the sizeof(void*) causes a syntax error in the preprocessor. Noticed by Debian when compiling with the upcoming gcc 4.4: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=505421 This ldap_int_thread.h snippet: #elif defined( HAVE_CTHREAD_H # include <cthreads.h> lacks a ')' and should test HAVE_CTHREAD*S*_H.

1 0

Re: (ITS#5823) clients/tools don't honor ldap.conf defaults
by hyc＠symas.com 20 Nov '08

20 Nov '08

Hallvard B Furuseth wrote: > hyc(a)OpenLDAP.org writes: >> I suggest that we use option==1 for on, and option>1 for off, to >> minimize the impact of the change. (E.g., to explicitly turn off >> referrals, use ldapsearch -CC.) > > That conflicts with today's -ZZ, which seems a bad option to > create confusion about. Also with ldapsearch -L[L[L]]. > > Another variant is -C = on and +C = off. Backwards, but it's > not our fault that Unix chose "-" for "on":-) Unless +foo > means something special on Windows command lines? > This may not be a big deal after all. The only options affected are -C and -N, and -C is essentially useless now. (And is undocumented.) So perhaps this can be mostly ignored, and we just need a workable approach for -N and any future boolean options. -- -- 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#5823) clients/tools don't honor ldap.conf defaults
by h.b.furuseth＠usit.uio.no 20 Nov '08

20 Nov '08

hyc(a)OpenLDAP.org writes: > I suggest that we use option==1 for on, and option>1 for off, to > minimize the impact of the change. (E.g., to explicitly turn off > referrals, use ldapsearch -CC.) That conflicts with today's -ZZ, which seems a bad option to create confusion about. Also with ldapsearch -L[L[L]]. Another variant is -C = on and +C = off. Backwards, but it's not our fault that Unix chose "-" for "on":-) Unless +foo means something special on Windows command lines? -- Hallvard

1 0

(ITS#5823) clients/tools don't honor ldap.conf defaults
by hyc＠OpenLDAP.org 20 Nov '08

20 Nov '08

Full_Name: Howard Chu Version: HEAD/RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc Various options in clients/tools/common.c are set as follows: /* referrals */ if( ldap_set_option( ld, LDAP_OPT_REFERRALS, referrals ? LDAP_OPT_ON : LDAP_OPT_OFF ) != LDAP_OPT_SUCCESS ) This means if the commandline option was provided, the option is turned on, otherwise it is turned off. I.e., the ldap.conf setting is completely overridden at all times. All of these options cases should be fixed to only issue the ldap_set_option() call if the corresponding argument was provided, to allow the default setting to take effect when the arguments are not provided. I suggest that we use option==1 for on, and option>1 for off, to minimize the impact of the change. (E.g., to explicitly turn off referrals, use ldapsearch -CC.)

1 0

Re: (ITS#5812) New option to disable SASL host canonicalization
by rra＠stanford.edu 20 Nov '08

20 Nov '08

Howard Chu <hyc(a)symas.com> writes: > The real problem is that the standard POSIX gethost/getaddr* APIs don't > tell you the confidence level of the information they return. Nor do > they let you specify a minimum acceptable confidence level when you make > a query. (Analogous to the SSFs we use in OpenLDAP.) Yeah, that would be great. There are, unfortunately, a bunch of problems with those interfaces. Blocking behavior is another problem with them. -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

Re: (ITS#5812) New option to disable SASL host canonicalization
by hyc＠symas.com 20 Nov '08

20 Nov '08

rra(a)stanford.edu wrote: > Howard Chu<hyc(a)symas.com> writes: > >> Leaving aside your followup which clarified this clause: the obvious >> point is that a Kerberos client needs to have trusted *local* data to >> protect against this attack. > > All Kerberos clients have trusted local data. It's required by the > Kerberos protocol; the server gives you a TGT that you can only decrypt > using your trusted local data. So I'm not sure what you're getting at > here. The problem with DNS canonicalization is that it allows you to > attack clients even if those clients have trusted local data to establish > mutual authentication with the KDC. This is going way beyond off topic but... The real problem is that the standard POSIX gethost/getaddr* APIs don't tell you the confidence level of the information they return. Nor do they let you specify a minimum acceptable confidence level when you make a query. (Analogous to the SSFs we use in OpenLDAP.) -- -- 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#5812) New option to disable SASL host canonicalization
by rra＠stanford.edu 20 Nov '08

20 Nov '08

My apologies for completely failing reading comprehension and including so much material that had already been mentioned in this ITS. I hadn't realized until I reviewed the whole ITS log just how much I'd duplicated of what people had already said. :/ -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

Re: (ITS#5812) New option to disable SASL host canonicalization
by hyc＠symas.com 20 Nov '08

20 Nov '08

geert(a)boskant.nl wrote: > Full_Name: Geert Jansen > Version: 2.4 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/geert-jansen-081115.patch > Submission from: (NULL) (12.230.186.195) > > > This is a resubmission of my earlier patch in [1]. I'm asking for this patch to > be included into OpenLDAP. > > The patch adds an LDAP option called LDAP_OPT_X_SASL_NOCANON to disable host > name canonicalization using reverse DNS for the host name that is passed into > SASL. Instead, it passes verbatim the host name part from the LDAP URI and lets > SASL do the canonicalization. The option is disabled by default. > Since some time MIT Kerberos has support for server-side canonicalization which > is an alternative for the DNS based scheme. By default it uses both, but with an > option "rdns = no", reverse DNS can be disabled. > > The use case for this is environments that do not have reverse DNS set up > correctly. Especially in Windows Active Directory environments this is very > common. Administrators are afraid to enable scavenging for their zones, and > therefore any server IP change will leave a stale PTR record in place. This > breaks reverse DNS based canonicalization if the IP adress is reassigned. > > The behaviour enabled by this patch should remain optional and cannot become the > default. It breaks the use case when multiple LDAP servers are load balanced > using a CNAME record. In reviewing this patch, I see some technical issues to resolve: 1) You seem to be making the ldap_set_option "arg" parameter optional; there appears to be no justification for this (significant) behavioral change. 2) If you're dealing with a KDC that supports this feature, then it would make the most sense for this to be a site-wide option. As such, it should be possible for the setting to become the default, and an ldap.conf keyword should exist to control that setting. 3) Your addition of the option to the command line tools is boolean; if the command line option is present the option will be turned on, otherwise it will be turned off. This requires too much knowledge on the part of the user running the tool, to decide whether they need the option or not. Again, it should allow a system-wide setting, and the command-line option should be tri-state: on / off / default. Users should not be required to learn about this option before using the commandline tools, the sysadmin should set it site-wide when the KDC is known to support it. -- -- 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#5820) segfault with slapacl
by ghenry＠OpenLDAP.org 20 Nov '08

20 Nov '08

----- ando(a)sys-net.it wrote: > Gavin Henry wrote: > >>> Anyone else seeing this? > >>> > >> Working here. > > > > I'm on 4.7.25 with patches, 32-bit. You? > > Same here. On a different 32-bit machine it passes on Head. Weird. Will check it out. -- 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#5812) New option to disable SASL host canonicalization
by rra＠stanford.edu 20 Nov '08

20 Nov '08

Howard Chu <hyc(a)symas.com> writes: > Leaving aside your followup which clarified this clause: the obvious > point is that a Kerberos client needs to have trusted *local* data to > protect against this attack. All Kerberos clients have trusted local data. It's required by the Kerberos protocol; the server gives you a TGT that you can only decrypt using your trusted local data. So I'm not sure what you're getting at here. The problem with DNS canonicalization is that it allows you to attack clients even if those clients have trusted local data to establish mutual authentication with the KDC. > Delegating administration authority still implies that you trust whoever > you delegated it to. Again, if you can't trust everyone then your > administrative procedures are broken and your framework has already been > compromised. Yes, it implies that you trust them to take the actions that you delegated to them. However, it *doesn't* imply that you trust them universally. You can delegate control of some principals and not others. That's a meaningful operation that is entirely valid within the Kerberos protocol trust model. Control of one principal in a realm should not imply an ability to spoof authentications to other principals in the same realm. Kerberos as a protocol can and is designed to be robust against attackers who have control over principals within your local realm provided that a client and a server agree on principal naming for a service. Kerberos clients are specifically cautioned in the Kerberos protocol specification against using insecure DNS to establish that agreement naming. Section 1.3 of RFC 4120, particularly the two paragraphs starting with: Implementations of Kerberos and protocols based on Kerberos MUST NOT use insecure DNS queries to canonicalize the hostname components of the service principal names (i.e., they MUST NOT use insecure DNS queries to map one name to another to determine the host part of the principal name with which one is to communicate). and the security considerations section of RFC 4752, namely: When constructing the input_name_string, the client SHOULD NOT canonicalize the server's fully qualified domain name using an insecure or untrusted directory service. are relevant here. The delegated administrative model that I describe is in widespread use; in fact, I don't know of any of my colleagues who *don't* do something similar to that. -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs