openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

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

02 Jun '10

On Jun 2, 2010, at 11:11 AM, Michael Str=F6der wrote: > Kurt(a)OpenLDAP.org wrote: >> However, one issue I have with this code is that highly dependent =3D >> behaviors which, aside from not be standardized, aren't even = specified =3D >> in RFCs. For instance, there is no RFC describing dnsHostName or =3D >> ldapServiceName or any specification detailing how GSS-SPNEGO is to = be =3D >> used in LDAP. Without a formal specification (e.g., RFC), I oppose =3D= >> release of this code. That is, it should stay HEAD only until such = time =3D >> that a formal specification (e.g., RFC) is available. >=20 > Kurt, I somewhat can understand your concerns. > But as a general answer to your comment above: There is already a lot = of code > in OpenLDAP for which no RFC or at least an I-D was specified but = which serves > a certain use-case. Strictly (following your statement above) speaking = one > would have to hunk out all the stuff only specified in I-Ds. An I-D would be a start. I would think there's a number of interesting = security considerations that would bubble up if someone would ever have = taken the time to submit a specification regarding use of SPNEGO in SASL = and in application protocols such as LDAP to an open standards = organization such as the IETF. > So I don't see > the strong need to be overly strict here. It's long been a stated goal of the project to promote interoperability = through open standards. This work seems more to come from a community = whose stated goal is to behave like one particular vendor. I'm not a = fan of chasing any particular vendor. > Quality of certain code is another story. But I cannot comment on = this. How can one independently verify the code acts as intended without a = specification of the intended behavior? (Saying it should act like = some particular commercial product, is not a specification.) -- Kurt >=20 > Ciao, Michael.

1 0

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

02 Jun '10

Kurt(a)OpenLDAP.org wrote: > However, one issue I have with this code is that highly dependent = > behaviors which, aside from not be standardized, aren't even specified = > in RFCs. For instance, there is no RFC describing dnsHostName or = > ldapServiceName or any specification detailing how GSS-SPNEGO is to be = > used in LDAP. Without a formal specification (e.g., RFC), I oppose = > release of this code. That is, it should stay HEAD only until such time = > that a formal specification (e.g., RFC) is available. Kurt, I somewhat can understand your concerns. But as a general answer to your comment above: There is already a lot of code in OpenLDAP for which no RFC or at least an I-D was specified but which serves a certain use-case. Strictly (following your statement above) speaking one would have to hunk out all the stuff only specified in I-Ds. So I don't see the strong need to be overly strict here. Quality of certain code is another story. But I cannot comment on this. Ciao, Michael.

1 0

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

02 Jun '10

On Jun 2, 2010, at 4:28 AM, gcarter(a)likewise.com wrote: >=20 > 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? There's already LDAP_AUTH_NEGOTIATE which does this. So technically, = the API is already exposed via ldap_bind_s. But I strongly oppose the introduction of abuse of the LDAP_AUTH_* = enumeration of LDAP authentication methods and ldap_bind_s(). This = enumeration and method are intended to have a one-to-one relationship = with the wire protocol. There is no "negotiate" LDAP authentication = mechanism. If this code is going to pursued (see my other comments), I think it = should be treated as a high level negotiation wrapper similar to = ldap_sasl_interactive_bind_s(). If at all possible, it should be = integrated into ldap_sasl_interactive_bind_s() (which can handle = non-interactive cases as well). However, I could (*) see it desirable = for it to be separately accessible as well, so = ldap_sasl_gss_spnego_bind_s() would be better. (* it might be easier to = see this if a proponent of this feature would implement it in = ldapwhoami(1) and slapd(8).) However, I still have objections to releasing code which implements = undocumented protocol features. Someone really needs to specify the the = SASL GSS-SPNEGO mechanism and how its used in LDAP. -- Kurt=20 >=20 >=20 >=20 >=20 >=20 >=20 > cheers, jerry > - --=20 > 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 >=20 >=20 >=20 >=20 >=20 > On 6/2/10 12:10 AM, Scott Salley wrote: >>=20 >>=20 >>=20 >> -----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 >>=20 >> 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 >> 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. >>=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 >> 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. >>=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 >=20 >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2.2 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >=20 > iD8DBQFMBj/7IR7qMdg1EfYRAjmcAKC1MyKit8TKa1W96cZ2Uh3Cdm/EMACeJtbu > 9/F8j8UQJ5C3X0sW5LytRq8=3D > =3DtkYo > -----END PGP SIGNATURE----- >=20 >=20

1 0

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

02 Jun '10

Lastly, I note that it might be good for proponent of this feature to at = least offer extensions to ldapwhoami(1) and other command line tools. = Aside from the educational value that would provide to developers in how = this feature would be used along side other libldap features (such as = ldap_sasl_interactive_bind_s), it would provide a means to test the = code. Of course, without support in OpenLDAP's slapd(8), testing would = be cumbersome for many. -- Kurt On Jun 1, 2010, at 6:08 PM, 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. >=20 > If you really want to have "direct" access to other authentication = mechanisms,=20 > 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. 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#6567) Enable GSSAPI support and expose ldap_gssadpi_bind_s
by Kurt＠OpenLDAP.org 02 Jun '10

02 Jun '10

In looking at the code a bit more closely, one could argue that what = this code actually provides is an alternative to = ldap_sasl_interactive_bind_s() which, instead of negotiating any = mechanism, is designed to negotiate GSS API mechanisms via GSS-SPNEGO. = In that light, maybe it should be integrated into = ldap_sasl_interactive_bind_s() or renamed to be more clear to be a = higher level negotiation routine, maybe ldap_sasl_gss_spnego_bind_s(). However, one issue I have with this code is that highly dependent = behaviors which, aside from not be standardized, aren't even specified = in RFCs. For instance, there is no RFC describing dnsHostName or = ldapServiceName or any specification detailing how GSS-SPNEGO is to be = used in LDAP. Without a formal specification (e.g., RFC), I oppose = release of this code. That is, it should stay HEAD only until such time = that a formal specification (e.g., RFC) is available. I would assume GSS-SPNEGO is usable without these attributes. It seems = odd to me that this code requires them. I note that use of the SASL GSS-SPNEGO in LDAP has actually be = discouraged in IETF circles because SASL "GSS-SPNEGO" is itself not well = specified and multiple levels of negotiation leads to downgrade attacks. = The general consensus in the IETF seems that application protocol = clients (including LDAP clients) should use SASL mechanism negotiation = to select mechanisms, whether GSS API based mechanisms or non GSS API = based mechanisms. There is a general move on foot that all new SASL = mechanisms be described as GSS API mechanisms, ala SCRAM. -- Kurt=

1 0

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

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