openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

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

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