openldap-bugs April 2010

openldap-bugs@openldap.org

45 participants
233 discussions

Re: (ITS#6194) Patch - Enhancement - provide LDIF support as libldif
by rmeggins＠redhat.com 09 Apr '10

09 Apr '10

Full_Name: Rich Megginson Version: CVS HEAD (2.4.21+) OS: Fedora URL: ftp://ftp.openldap.org/incoming/openldap-2.4.21-libldif-and-new-ldif-api-20… This patch allows liblutil to provide the LDIF reading and writing functions as public APIs in a libldif, and exposes ldif.h to the public API. This patch also creates a new LDAP API for parsing raw LDIF records into higher level LDAP structures such as LDAPMod and LDAPControl - ldap_parse_ldif_record() - and changes ldapmodify.c to use the new API. This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat, Inc.. Red Hat, Inc. has not assigned rights and/or interest in this work to any party. I, Richard Megginson am authorized by Red Hat, Inc., my employer, to release this work under the following terms. Red Hat, Inc. hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#6510) GSSAPI rebind proc will cause mutex deadlock
by hyc＠symas.com 09 Apr '10

09 Apr '10

Kurt(a)OpenLDAP.org wrote: > On Apr 8, 2010, at 8:08 PM, Howard Chu wrote: > >> Kurt(a)OpenLDAP.org wrote: >>> On Apr 8, 2010, at 3:58 PM, hyc(a)symas.com wrote: >>> =20 >>>> Sounds like your servers are mis-configured, it is not legal to send = > a=3D20=3D >>> =20 >>>> referral in response to a Bind request. >>> =20 >>> I note that the technical specification doesn't actually preclude = > return =3D >>> of a referral in response to a Bind request. However, in practice, = > such =3D >>> return is quite problematic due to ambiguous semantics and security =3D= > >>> considerations. >> =20 >> Right. I can't find the discussion we had about this back in 2004, but = > certainly we've already hashed this out in great detail before. >> =20 >> The fact is that acting on a referral simply means performing a Bind = > against some other server. >> It does nothing for the authentication state of the session on the = > original server. > > Right, by returning a referral, regardless of how far the client got in = > authentication process (including completion of all challenges), the = > client is now anonymous at the original server. > > And there's a security concern, the referral information is not = > protected by the underlying authentication mechanism. It is actually = > quite possible that this be used by an attacker to cause the client to = > try authentication multiple times, possibly with chosen plaintext. > > I recommend that the library never chase bind referrals. Agreed. Patched in HEAD. > (I tend to = > think of rebind as a misfeature. Robust clients really should be using = > the async API and carefully managing security contexts and chasing.) -- -- 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#6511) syncrepl unreliable, stops when master is temporary unreachable
by quanah＠zimbra.com 09 Apr '10

09 Apr '10

--On Friday, April 09, 2010 10:23 AM +0000 wilco(a)baanhofman.nl wrote: > Full_Name: Wilco Baan Hofman > Version: 2.4.11 > OS: Debian > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (86.82.223.18) Please don't file bug reports against ancient releases. The current stable release is OpenLDAP 2.4.21. If you can reproduce your issue using that release, then file an ITS. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6511) syncrepl unreliable, stops when master is temporary unreachable
by masarati＠aero.polimi.it 09 Apr '10

09 Apr '10

> Behaviour: > Syncrepl stops working when the master server is temporarily unreachable > or > restarted. > > Expected behaviour: > Retrying to connect indefinatly, once every 10 to 30 seconds. > > Result: > This means we have to restart slapd every time there has been a slight > glitch in > the internet connection. I assume you did not read this <http://www.openldap.org/faq/data/cache/56.html> before filing the bug report. In any case, even assuming the behavior you report is caused by a bug (you are not providing any information that is vaguely useful to this extent), there has been substantial development since 2.4.11, specifically in the area of syncrepl. Unless the issue reproduces in the latest release, there is no point in even starting tracking it down. p.

1 0

(ITS#6511) syncrepl unreliable, stops when master is temporary unreachable
by wilco＠baanhofman.nl 09 Apr '10

09 Apr '10

Full_Name: Wilco Baan Hofman Version: 2.4.11 OS: Debian URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (86.82.223.18) Hi, Behaviour: Syncrepl stops working when the master server is temporarily unreachable or restarted. Expected behaviour: Retrying to connect indefinatly, once every 10 to 30 seconds. Result: This means we have to restart slapd every time there has been a slight glitch in the internet connection. Regards, Wilco Baan Hofman

1 0

Re: (ITS#6510) GSSAPI rebind proc will cause mutex deadlock
by Kurt＠OpenLDAP.org 08 Apr '10

08 Apr '10

On Apr 8, 2010, at 8:08 PM, Howard Chu wrote: > Kurt(a)OpenLDAP.org wrote: >> On Apr 8, 2010, at 3:58 PM, hyc(a)symas.com wrote: >>=20 >>> Sounds like your servers are mis-configured, it is not legal to send = a=3D20=3D >>=20 >>> referral in response to a Bind request. >>=20 >> I note that the technical specification doesn't actually preclude = return =3D >> of a referral in response to a Bind request. However, in practice, = such =3D >> return is quite problematic due to ambiguous semantics and security =3D= >> considerations. >=20 > Right. I can't find the discussion we had about this back in 2004, but = certainly we've already hashed this out in great detail before. >=20 > The fact is that acting on a referral simply means performing a Bind = against some other server. > It does nothing for the authentication state of the session on the = original server. Right, by returning a referral, regardless of how far the client got in = authentication process (including completion of all challenges), the = client is now anonymous at the original server. And there's a security concern, the referral information is not = protected by the underlying authentication mechanism. It is actually = quite possible that this be used by an attacker to cause the client to = try authentication multiple times, possibly with chosen plaintext. I recommend that the library never chase bind referrals. (I tend to = think of rebind as a misfeature. Robust clients really should be using = the async API and carefully managing security contexts and chasing.) -- Kurt=

1 0

Re: (ITS#6510) GSSAPI rebind proc will cause mutex deadlock
by hyc＠symas.com 08 Apr '10

08 Apr '10

Kurt(a)OpenLDAP.org wrote: > On Apr 8, 2010, at 3:58 PM, hyc(a)symas.com wrote: > >> Sounds like your servers are mis-configured, it is not legal to send a=20= > >> referral in response to a Bind request. > > I note that the technical specification doesn't actually preclude return = > of a referral in response to a Bind request. However, in practice, such = > return is quite problematic due to ambiguous semantics and security = > considerations. Right. I can't find the discussion we had about this back in 2004, but certainly we've already hashed this out in great detail before. The fact is that acting on a referral simply means performing a Bind against some other server. It does nothing for the authentication state of the session on the original server. -- -- 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#6510) GSSAPI rebind proc will cause mutex deadlock
by Kurt＠OpenLDAP.org 08 Apr '10

08 Apr '10

On Apr 8, 2010, at 3:58 PM, hyc(a)symas.com wrote: > Sounds like your servers are mis-configured, it is not legal to send a=20= > referral in response to a Bind request. I note that the technical specification doesn't actually preclude return = of a referral in response to a Bind request. However, in practice, such = return is quite problematic due to ambiguous semantics and security = considerations. -- Kurt

1 0

Re: (ITS#6510) GSSAPI rebind proc will cause mutex deadlock
by hyc＠symas.com 08 Apr '10

08 Apr '10

inlovewithGod(a)gmail.com wrote: > Full_Name: Jeremiah Martell > Version: 2.4.21 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (192.146.101.71) > > > I have three windows active directory servers setup: > childA.parent.example.com > parent.example.com > childB.parent.example.com > > I do a LDAP+GSSAPI bind to childA.parent.example.com. > The bind succeeds. > > I do a search that returns referrals, (I know I need to be referred to > parent, and then childB in order to find my result), > and I have openldap follow referrals for me. > > My rebind proc is a function that only calls: > ldap_sasl_interactive_bind_s( ld, NULL, NULL, NULL, NULL, > LDAP_SASL_AUTOMATIC, sasl_driver, params ); > where sasl_driver and params is the same parameters that I used for > the initial bind call to childA. > > After the seach call, the debug looks like this: > >> ldap_chase_v3referrals, where ref[0] = parent.example.com > > myGSSAPIrebindProc > > ldap_sasl_interactive_bind_s > < ldap_sasl_interactive_bind_s > < myGSSAPIrebindProc > < ldap_chase_v3referrals > >> ldap_chase_v3referrals, where ref[0] = childB.parent.example.com > > myGSSAPIrebindProc > > ldap_sasl_interactive_bind_s > > ldap_chase_v3referrals, where ref[0] = childA.parent.example.com > < ldap_chase_v3referrals > > ldap_chase_v3referrals, where ref[0] = > ForestDnsZones.parent.example.com > > myGSSAPIrebindProc > > ldap_sasl_interactive_bind_s ... HANG ON MUTEX > > I changed openldap to make all mutex's recursive, and this fixed my problem. I > was then able to search, chase referrals, bind to referrals with > ldap_sasl_interactive_bind_s, and eventually find my result. Sounds like your servers are mis-configured, it is not legal to send a referral in response to a Bind request. -- -- 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#6507) backglue and paged results issue
by masarati＠aero.polimi.it 08 Apr '10

08 Apr '10

> Ah yes, just saw this. Sorry, my email seems to be slow today (weird). > > Similar to my patch, but I'm unsure about the second part: > > } else if ( op->o_bd != gi->gi_n[0].gn_be ) { > /* if cookie not empty, it's again this database's turn */ > op->o_conn->c_pagedresults_state.ps_be = op->o_bd; > } > > If the cookie is not empty, then it should again be this database's > turn, even it this is this last database. > > This makes a search that stops in the middle of results from last > database with a valid cookie fall back to the first database on > continuation, and thus loop forever. > > Would you consider removing the else if? Well, it's not that simple. The fact is that paged results state is being handled in two ways: when the database is back-bdb/hdb, the cookie is an ID, and it's stored in ps_cookie; otherwise (e.g. back-ldap), it's a berval, stored in ps_cookieval. I need to handle both cases. I think I made it. Now, ps_cookie in c_pagedresults_state is initialized to NOID; back-bdb will set it to 0 first, and then to whatever value it needs. Other backends, that use ps_cookieval, will not touch it. So when ps_cookie == NOID one needs to look at ps_cookieval (and parse it as needed), otherwise ps_cookie suffices. You'll need to update backglue.c, controls.c and back-bdb/search.c. Now it passes all cases I checked, both with local glued databases and with back-null/back-ldap as in your example. p.

1 0

← Newer
1
...
16
17
18
19
20
21
22
23
24
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs April 2010