openldap-bugs June 2010

openldap-bugs@openldap.org

23 participants
57 discussions

Re: (ITS#6567) Enable GSSAPI support and expose ldap_gssadpi_bind_s
by hyc＠symas.com 01 Jun '10

01 Jun '10

ssalley(a)likewise.com wrote: > Full_Name: Scott Salley > Version: HEAD > OS: Linux > URL: http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-defi… > Submission from: (NULL) (67.51.54.234) > > > Note that a similar issue/contribution was submitted in 2008 (Contrib/5369) and > appears to have been 'lost'. > The patch http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-defi… > makes it possible to use the GSSAPI support in OpenLDAP by: > > 1. Defining --with-gssapi in configure which > a. Checks for appropriate header files > b. Checks for the appropriate library > c. Defines HAVE_GSSAPI to 1 in everything is in order > > 2. Exposing ldap_gssapi_bind_s in ldap.h I am still disinclined to publish any of this. The standard mechanism for using GSSAPI in LDAP is via SASL. I see no benefit to propagating more non-standard one-off ldap_XXX_bind flavors. It's a poor design approach and it increases our support workload for no appreciable gain. It increases application developer's workload as well, if they have to test for the existence of multiple flavors of ldap_XXX_bind and code for them each separately in their apps. If you really want to have "direct" access to other authentication mechanisms, the right way to do this is by adding new LDAP_AUTH_xxx definitions that can be muxed out from a single ldap_bind API. Of course, by the time you've implemented option parsing so that generic client code can be configured with arbitrary Bind mechanisms, you would have re-implemented SASL. -- -- 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#6569) patch: Set ld_errno on error.
by ssalley＠likewise.com 01 Jun '10

01 Jun '10

Full_Name: Scott Salley Version: HEAD OS: Ubuntu URL: http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-set-… Submission from: (NULL) (67.51.54.234) The patch http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-set-… ensures ld_errno is set to an error when there is no valid result.

1 0

(ITS#6568) patch: Memory leak in connectionless
by ssalley＠likewise.com 01 Jun '10

01 Jun '10

Full_Name: Scott Salley Version: HEAD OS: Ubuntu URL: http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-fix-… Submission from: (NULL) (67.51.54.234) The patch http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-fix-… closes memory leaks associated with using connectionless mode.

1 0

(ITS#6567) Enable GSSAPI support and expose ldap_gssadpi_bind_s
by ssalley＠likewise.com 01 Jun '10

01 Jun '10

Full_Name: Scott Salley Version: HEAD OS: Linux URL: http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-defi… Submission from: (NULL) (67.51.54.234) Note that a similar issue/contribution was submitted in 2008 (Contrib/5369) and appears to have been 'lost'. The patch http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-defi… makes it possible to use the GSSAPI support in OpenLDAP by: 1. Defining --with-gssapi in configure which a. Checks for appropriate header files b. Checks for the appropriate library c. Defines HAVE_GSSAPI to 1 in everything is in order 2. Exposing ldap_gssapi_bind_s in ldap.h

1 0

(ITS#6566) rwm, ppolicy, sssvlv, and valsort display warnings on STDERR
by mhardin＠symas.com 01 Jun '10

01 Jun '10

Full_Name: Matt Hardin Version: 2.4.22 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (74.38.117.141) rwm, ppolicy, sssvlv, and valsort display warnings on STDERR, not syslog. It seems these warnings should go into syslog instead.

1 0

Re: (ITS#6565) DNSSRV referrals: chaining without search base
by masarati＠aero.polimi.it 01 Jun '10

01 Jun '10

> Hi, > this is a partly duplicate of ITS 6463: I think it's better to split > these 2 > items into 2 separate ITS. > > This ITS only describes the behaviour of OpenLDAP using referrals > generated by > DNSSRV; just ldap (no ldaps) is used. > > You stated that not returning DNs in DNSSRV "conforms to RFC4511". This > seems to > be OK. Nevertheless these returned URLs are used in the chaining code. > > This means that the chained search always searches with base "" (root). I > don't > think that this the right behavior. > > I debugged the code several hours but couldn't find a solution. What I > could > see: > - dnssrv_back_referrals just puts server names into the referral structure > ("ref") > - the functions called afterwards - esp. ldap_chain_op - parse this > structure > "ref" for server names AND DNs (search bases) > > I'm sorry, my knowledge of the OpenLDAP code is not deep enough to propose > a > solution. But I think that this should be fixed: Chained Searches with "" > as > search base in a distributed environment can't really work: problems like > - some servers don't support this kind of search > - loop detection > - access control > are there. Hi. I don't have time to work at this right now, but I think the solution would be to modify slapo-chain(5) so that when a referral's DN is "" and the DN in the original request is not "", to use that DN instead. The original request DN can be found in op->o_req_dn. p.

1 0

(ITS#6565) DNSSRV referrals: chaining without search base
by jochen＠keutel.de 01 Jun '10

01 Jun '10

Full_Name: Jochen Keutel Version: 2.4.22 OS: Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.159.200.236) Hi, this is a partly duplicate of ITS 6463: I think it's better to split these 2 items into 2 separate ITS. This ITS only describes the behaviour of OpenLDAP using referrals generated by DNSSRV; just ldap (no ldaps) is used. You stated that not returning DNs in DNSSRV "conforms to RFC4511". This seems to be OK. Nevertheless these returned URLs are used in the chaining code. This means that the chained search always searches with base "" (root). I don't think that this the right behavior. I debugged the code several hours but couldn't find a solution. What I could see: - dnssrv_back_referrals just puts server names into the referral structure ("ref") - the functions called afterwards - esp. ldap_chain_op - parse this structure "ref" for server names AND DNs (search bases) I'm sorry, my knowledge of the OpenLDAP code is not deep enough to propose a solution. But I think that this should be fixed: Chained Searches with "" as search base in a distributed environment can't really work: problems like - some servers don't support this kind of search - loop detection - access control are there. Regards, Jochen.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs June 2010