openldap-bugs

openldap-bugs@openldap.org

1 participants
20966 discussions

Re: FW: (ITS#6567) Enable GSSAPI support and expose ldap_gssadpi_bind_s
by gcarter＠likewise.com 02 Jun '10

02 Jun '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Howard, We are trying to make likewise-open packages available for Fedora but they only want to pull OpenLDAP patches from upstream. So I'm in a bit of a spot here. You've already accepted the lsap_bind_gssapi patch, this one simply exposes the existing code. Is it just the public ldap_bind_gssapi_s() signature that you have an issue with? If, as you suggest, we give you a patch that adds an LDAP_AUTH_GSSAPI flag to ldap_bind_s() but keep the same (existing) ldap_bind_gssapi_s() internals, would that be acceptable? cheers, jerry - -- Director of Engineering http://www.likewise.com/ Likewise-CIFS http://www.likewiseopen.org/ "What man is a man who does not make the world better?" --Balian On 6/2/10 12:10 AM, Scott Salley wrote: > > > > -----Original Message----- > From: Howard Chu [mailto:hyc@symas.com] > Sent: Tue 6/1/2010 6:07 PM > To: Scott Salley > Cc: openldap-its(a)openldap.org > Subject: Re: (ITS#6567) Enable GSSAPI support and expose ldap_gssadpi_bind_s > > 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/ > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFMBj/7IR7qMdg1EfYRAjmcAKC1MyKit8TKa1W96cZ2Uh3Cdm/EMACeJtbu 9/F8j8UQJ5C3X0sW5LytRq8= =tkYo -----END PGP SIGNATURE-----

1 0

Re: (ITS#6536) Autogroup overlay enhancement
by raphael.ouazana＠linagora.com 02 Jun '10

02 Jun '10

Le Mer 2 juin 2010 03:44, Howard Chu a écrit : > The code patch looks OK to me, but could you also provide a patch for the > README file summarizing this new behavior? I'm not too keen on supporting > groups of anything other than DNs in general, but I see the usefulness of > it. > However the potential performance hit can be quite a concern. Thank you for your feedback. Here is the patch of the README file: ftp://ftp.openldap.org/incoming/raphael-ouazana-autogroup-readme-1000602.pa… Regards, Raphaël Ouazana.

1 0

Re: (ITS#6362) slapd 2.4.19 Segmentation fault under load
by alexs＠ulgsm.ru 01 Jun '10

01 Jun '10

* alexs(a)ulgsm.ru <alexs(a)ulgsm.ru> [2010-01-19 07:25:25 +0000]: > * alexs(a)ulgsm.ru <alexs(a)ulgsm.ru> [2009-11-05 07:43:02 +0000]: > > OpenLDAP 2.4.22, 8.1-PRERELEASE is still crashed. > > > New OpenLdapd 2.4.21 on new freebsd 8.0 is still crashed. > I can make a public test server, to let some one check my configs and > see faults. > > Also intresting have any body same failures? > > > > > > Full_Name: Aleksey > > Version: 2.4.19 > > OS: Freebsd7.2 > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (93.93.136.26) > > > > > > Openldap 2.4.19 installed from freebsd ports. All configs in defauls > > Freebsd 7.2 amd64 > > Slapd built with the "-g" flag and install with the make install STRIP="" > > > > Used backends db46-4.6.21.4, db47-4.7.25.4 latest from freebsd ports. > > In slapd config added using hdb as backend and indexes. > > > > Testing database consist of 1000 users accounts with minimum attributes. > > > > On stress test load slapd Segmentation fault in 10-30 sec. > > > > > > #ldd /usr/local/libexec/slapd > > /usr/local/libexec/slapd: > > libldap_r-2.4.so.7 => /usr/local/lib/libldap_r-2.4.so.7 (0x80073b000) > > liblber-2.4.so.7 => /usr/local/lib/liblber-2.4.so.7 (0x800881000) > > libltdl.so.7 => /usr/local/lib/libltdl.so.7 (0x80098e000) > > libdb-4.6.so.0 => /usr/local/lib/libdb-4.6.so.0 (0x800a97000) > > libssl.so.5 => /usr/lib/libssl.so.5 (0x800ccf000) > > libcrypto.so.5 => /lib/libcrypto.so.5 (0x800e19000) > > libfetch.so.5 => /usr/lib/libfetch.so.5 (0x8010ab000) > > libcom_err.so.4 => /usr/lib/libcom_err.so.4 (0x8011b9000) > > libcrypt.so.4 => /lib/libcrypt.so.4 (0x8012bb000) > > libwrap.so.5 => /usr/lib/libwrap.so.5 (0x8013d4000) > > libthr.so.3 => /lib/libthr.so.3 (0x8014dd000) > > libc.so.7 => /lib/libc.so.7 (0x8015f5000) > > > > > > > > > > #gdb /usr/local/libexec/slapd > > (gdb) run -d 0 > > Starting program: /usr/local/libexec/slapd -d 0 > > [New LWP 100311] > > [New Thread 0x801a020b0 (LWP 100311)] > > [New Thread 0x801a02880 (LWP 100073)] > > [New Thread 0x8034040b0 (LWP 100076)] > > [New Thread 0x803404240 (LWP 100077)] > > [New Thread 0x8034043d0 (LWP 100078)] > > [New Thread 0x803404560 (LWP 100116)] > > > > Program received signal SIGSEGV, Segmentation fault. > > [Switching to Thread 0x803404560 (LWP 100116)] > > 0x0000000802d5aa4b in hdb_idl_fetch_key (be=Error accessing memory address > > 0x7ffffd9f9f38: Bad s. > > ) at idl.c:511 > > 511 { > > (gdb) > > (gdb) > > (gdb) where > > #0 0x0000000802d5aa4b in hdb_idl_fetch_key (be=Error accessing memory > > address 0x7ffffd9f9f38: dress. > > ) at idl.c:511 > > #1 0x0000000802d50dc5 in hdb_key_read (be=0x801a853d0, db=0x803519800, > > txn=0x80352b040, k=0x8069005 > > 70, ids=0x806a00000, saved_cursor=0x0, get_flag=0) at key.c:50 > > #2 0x0000000802d5363c in equality_candidates (op=0x803521000, rtxn=0x80352b040, > > ava=0x7ffffda7a4f0, > > ids=0x806c00000, tmp=0x806a00000) at filterindex.c:788 > > #3 0x0000000802d51d10 in hdb_filter_candidates (op=0x803521000, > > rtxn=0x80352b040, f=0x7ffffda7a550, > > ids=0x806c00000, tmp=0x806a00000, stack=0x806d00000) at filterindex.c:154 > > #4 0x0000000802d5297f in list_candidates (op=0x803521000, rtxn=0x80352b040, > > flist=0x7ffffda7a5 f > > type=161, ids=0x806b00000, tmp=0x806a00000, save=0x806c00000) at > > filterindex.c:581 > > #5 0x0000000802d5229c in hdb_filter_candidates (op=0x803521000, > > rtxn=0x80352b040, f=0x7ffffda7a530, > > ids=0x806b00000, tmp=0x806a00000, stack=0x806c00000) at filterindex.c:204 > > #6 0x0000000802d5297f in list_candidates (op=0x803521000, rtxn=0x80352b040, > > flist=0x7ffffda7a5 f > > type=160, ids=0x7ffffdafa760, tmp=0x806a00000, save=0x806b00000) at > > filterindex.c:581 > > #7 0x0000000802d521e4 in hdb_filter_candidates (op=0x803521000, > > rtxn=0x80352b040, f=0x7ffffda7a570, > > ids=0x7ffffdafa760, tmp=0x806a00000, stack=0x806b00000) at filterindex.c: > > #8 0x0000000802d4dca9 in search_candidates (op=0x803521000, rs=0x7ffffdbfab30, > > e=0x7ffffda7a71 tx > > n=0x80352b040, ids=0x7ffffdafa760, scopes=0x7ffffda7a760) at search.c:1206 > > #9 0x0000000802d4befa in hdb_search (op=0x803521000, rs=0x7ffffdbfab30) at > > search.c:586 > > #10 0x0000000000439bb5 in fe_op_search (op=0x803521000, rs=0x7ffffdbfab30) at > > search.c:366 > > #11 0x0000000000439520 in do_search (op=0x803521000, rs=0x7ffffdbfab30) at > > search.c:217 > > #12 0x000000000043613d in connection_operation (ctx=0x7ffffdbfac70, > > arg_v=0x803521000) at connection > > .c:1123 > > #13 0x00000000004366d9 in connection_read_thread (ctx=0x7ffffdbfac70, argv=0x12) > > at connection.c:125 > > 9 > > #14 0x0000000800797052 in ldap_int_thread_pool_wrapper () from > > /usr/local/lib/libldap_r-2.4.so. > > #15 0x000000080164b4d1 in pthread_getprio () from /lib/libthr.so.3 > > #16 0x0000000000000000 in ?? () > > Error accessing memory address 0x7ffffdbfb000: Bad address. -- alexs

1 0

Re: (ITS#6567) Enable GSSAPI support and expose ldap_gssadpi_bind_s
by Kurt＠OpenLDAP.org 01 Jun '10

01 Jun '10

On Jun 2, 2010, at 1:08 AM, hyc(a)symas.com wrote: > ssalley(a)likewise.com wrote: >> Full_Name: Scott Salley >> Version: HEAD >> OS: Linux >> URL: = http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-def= ine-have-gssapi.patch >> Submission from: (NULL) (67.51.54.234) >>=20 >>=20 >> Note that a similar issue/contribution was submitted in 2008 = (Contrib/5369) and >> appears to have been 'lost'. >=20 >> The patch = http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-def= ine-have-gssapi.patch >> makes it possible to use the GSSAPI support in OpenLDAP by: >>=20 >> 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 >>=20 >> 2. Exposing ldap_gssapi_bind_s in ldap.h >=20 > I am still disinclined to publish any of this. The standard mechanism = for=20 > using GSSAPI in LDAP is via SASL. I see no benefit to propagating more=20= > non-standard one-off ldap_XXX_bind flavors. It's a poor design = approach and it=20 > increases our support workload for no appreciable gain. It increases=20= > application developer's workload as well, if they have to test for the=20= > existence of multiple flavors of ldap_XXX_bind and code for them each=20= > separately in their apps. I concur and add: At one time I thought it might be useful to implement = a few SASL mechanisms directly in libldap for cases where one didn't = want to suck in a SASL library. But for most mechanisms removing the = SASL library is worth it in my eyes, especially any mechanism other than = PLAIN or EXTERNAL. But where this is worth it, it should be done = through existing APIs. Adding mech specific APIs should be avoided. >=20 > 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=20 > be muxed out from a single ldap_bind API. I could see adding new API to support new authentication frameworks to = which LDAP was extended to support. For instance, if LDAP was extended = to directly support GSS API mechanisms, then adding LDAP_AUTH_GSSAPI = would make sense (here GSS API refers to the GSS API not the SASL = Kerberos mechanism called GSSAPI). But for security reasons, it = unlikely this will ever happen, =20 > Of course, by the time you've=20 > implemented option parsing so that generic client code can be = configured with=20 > arbitrary Bind mechanisms, you would have re-implemented SASL. >=20 > --=20 > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ >=20 >=20

1 0

Re: (ITS#6536) Autogroup overlay enhancement
by hyc＠symas.com 01 Jun '10

01 Jun '10

raphael.ouazana(a)linagora.com wrote: > Full_Name: Raphael Ouazana > Version: 2.4.21 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/raphael-ouazana-autogroup-100427.patch > Submission from: (NULL) (213.41.232.151) > > > Hi, > > The attached patch allow the autogroup overlay to handle correctly the attr part > of the URL ldap://dc=example,dc=com?attr?sub?(filter). Before this patch, the > attr part was simply ignored. Now the group entry is populated by the values of > the attribute attr in the resulting entries. > > Implementation details: > Some cases (modify, delete) are harder to handle when you store values instead > of dn. In this cases the overlay try to detect if groups have been modified and > then simply refresh them. This can cause performance hits if the search > specified by the URL deals with an important number of entries. > > Legal notice: > This patch file is derived from OpenLDAP Software. All of the modifications to > OpenLDAP Software represented in this following patch were developed by Raphael > Ouazana raphael.ouazana(a)linagora.com. These modifications are not subject to > any > license of Linagora. > > The attached modifications to OpenLDAP Software are subject to the following > notice: > Copyright 2010 Raphael Ouazana, Linagora > Redistribution and use in source and binary forms, with or without > modification, > are permitted only as authorized by the OpenLDAP Public License. The code patch looks OK to me, but could you also provide a patch for the README file summarizing this new behavior? I'm not too keen on supporting groups of anything other than DNs in general, but I see the usefulness of it. However the potential performance hit can be quite a concern. -- -- 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#6569) patch: Set ld_errno on error.
by hyc＠symas.com 01 Jun '10

01 Jun '10

ssalley(a)likewise.com wrote: > 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. > Thanks for the report. Actually the Notice of Disconnect comes with an error code from the server, and that's actually what should be returned to the client here. Fixed in HEAD. -- -- 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#6568) patch: Memory leak in connectionless
by hyc＠symas.com 01 Jun '10

01 Jun '10

ssalley(a)likewise.com wrote: > 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. > Thanks for the patch, applied to HEAD. -- -- 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#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

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