- openldap-bugs - openldap.org

(ITS#6516) Proxy backends normalize ordered attrs incorrectly
by masarati＠aero.polimi.it 12 Apr '10

12 Apr '10

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.72.165.199) Submitted by: ando They need to use ordered_value_*() functions instead. A patch is coming. p.

1 0

Re: (ITS#6513) dynacl/aci fails on searches with attributes
by masarati＠aero.polimi.it 12 Apr '10

12 Apr '10

>> Full_Name: Peter Marschall >> Version: 2.4.21 >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/Peter-Marschall-100411.patch >> Submission from: (NULL) (94.217.135.20) >> >> >> Hi, >> >> Playing around with dynacl/aci a bit I cam across the following issue: >> >> Searches that do not contain the attribute OpenLDAPaci in the list of >> attribues >> queried, omit objects. > > dynacl/aci (as the original aci code it's based on) relies on the fact > that the entry is complete. This is the case when the entry is stored > locally, e.g. in back-bdb/hdb. Otherwise, no mechanism is in place to > retrieve operational attributes. Please note that in the latter case, > even ACL rules based on, say, createTimestamp or so would operate > incorrectly. > > My guess is that you're trying to use ACIs with a non-local storage. In > that case your analysis is correct. Can you provide your (sanitized) > configuration? > > The "right" solution is much more general, not only related to dynacl. > Slapd needs to know in advance what (operational) attributes are required > for policy enforcing, and they need to be added to requested attrs when > entries are collected from remote storage. Your patch seems to fix your > specific need, but it is clearly inefficient. Automatically detecting what attributes need to be added to requests for proxying sounds like an overkill. Probably, a reasonable workaround could be to add a configuration directive that lists what attributes need to be added to requests. This directive should be honored by proxy backends and in general by all those backends that do not pass back complete entries to the frontend. In the case of proxy backends its use would be straightforward, since requested attrs need to be mapped anyway in the request. Adding some more would not be a big deal. Things might be a bit more complicated in case of, say, special configurations like proxycache, where ACIs would need to be added to all attribute templates, and so. Yet another reason to avoid ACIs :) p.

1 0

Re: (ITS#6514) bindDN-rewriting with rwm+relay doesn't seem to work
by masarati＠aero.polimi.it 12 Apr '10

12 Apr '10

> Full_Name: Thomas Wunder > Version: 2.4.17 > OS: debian sqeueeze amd64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (141.13.106.69) I don't see a clear evidence of a bug. Software usage questions must be directed to the openldap-software list. Moreover, I just tried your verbatim configuration with the most recent code (while you're using an older release), and it seems to work as expected. This ITS will be closed. p. > I'm currently using the rwm overlay to filter the objects from my > ou=students,dc=uni-bamberg,dc=de directory by their "o"-attribute and > project > the result to ou=students,ou=people,ou=swt,ou=wiai,dc=uni-bamberg,dc=de > Therefore I use the following section within my slapd.conf (before the > "database > hdb..." section): > > database relay > suffix > "ou=students,ou=people,ou=swt,ou=wiai,dc=uni-bamberg,dc=de" > overlay rwm > #rwm-rewriteEngine on > rwm-suffixmassage > "ou=students,ou=people,ou=swt,ou=wiai,dc=uni-bamberg,dc=de" > > "ou=students,dc=uni-bamberg,dc=de" > rwm-rewriteContext bindDN > rwm-rewriteRule ".*" "cn=ldapadmin,dc=uni-bamberg,dc=de" ":@" > rwm-rewriteContext searchFilter > rwm-rewriteRule "(.*)" "(&(o=swt)$1)" ":@I" > > searchFilter rewriting works perfectly but I also need to rewrite the > bindDN as > every operation within ou=students,dc=uni-bamberg,dc=de needs to be > carried out > by a particular user (cn=ldapadmin,dc=uni-bamberg,dc=de) > (the reason is that i don't want any user other than ldapadmin to be able > to > write ou=students,dc=uni-bamberg,dc=de but they should be able to modifiy > entries within ou=students,ou=people,ou=swt,ou=wiai,dc=uni-bamberg,dc=de) > according to the logs and the error reply messages there seems to be no > binndn > rewriting done... > It looks like the rule never matches. > Is my rule not general enough to match each possible bindDN-String? Is > "cn=ldapadmin,dc=uni-bamberg,dc=de" (replacement string for the bindDN) > not well > formatted (does it expect something else)? Does the overlay "relay" > prevent the > replacement of the bindDN? > > As you can see I don't have any idea what might be causing my problem and > I hope > you can help me. > > >

1 0

Re: (ITS#6507) backglue and paged results issue
by jonathan＠phillipoux.net 12 Apr '10

12 Apr '10

Le 08/04/2010 19:26, masarati(a)aero.polimi.it a écrit : >> 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. Right - I'd missed that, regarding this difference between hdb/bdb databases and others. Thanks for the explanation! Just tested your lasted patch set, and it all works great for me, in various different scenarios. Thanks a lot. Jonathan -- -------------------------------------------------------------- Jonathan Clarke - jonathan(a)phillipoux.net -------------------------------------------------------------- Ldap Synchronization Connector (LSC) - http://lsc-project.org --------------------------------------------------------------

1 0

Re: (ITS#6432) PATCH: MozNSS crypto (tls_m.c) - support InitContext, improved PEM support
by richm＠stanfordalumni.org 12 Apr '10

12 Apr '10

hyc(a)symas.com wrote: > rmeggins(a)redhat.com wrote: > >> Any update on this? >> > > Sorry I must've missed your last reply, I thought we were still waiting on you. > > Why is pem_mod_name needed as an independent variable? Since it's const I > presume it will not be changing in the future? > I guess it doesn't really matter. It may change if the PEM module decides to change its name, but that is not likely. > (Not asking for a change here, just want to understand its purpose.) > > Actually, since it and pem_library are only used once each, I would probably > just #define it instead. But again, just want to know first how constant it > really is. > See above - it doesn't matter to me either, it could be #define'd or even hard coded in the module init string. Just let me know. > I've committed the patch as-is. If any other tweaks are needed let us know. > Thanks for working on this. > Thanks!

1 0

(ITS#6515) A lot of dead links on main page of OpenLDAP man.
by mitroko＠gmail.com 12 Apr '10

12 Apr '10

Full_Name: Dmitry Stremkouski Version: OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (95.84.189.132) Hello guys. The part of OpenLDAP Manual (wich can be found here - http://www.openldap.org/doc/admin23/schema.html) contains a lot of broken links. Please correct. FE: http://www.alvestrand.no/harald/objectid/ - dead A: http://www.bsa-global.com/ - dead (doesn't look good enough for global OID authority) A: http://www.iana.org/cgi-bin/enterprise.pl - should be (redirect, but futher, IMHO, will be dead, try http://pen.iana.org/pen/PenApplication.page) Thanks.

1 0

(ITS#6514) bindDN-rewriting with rwm+relay doesn't seem to work
by thomas.wunder＠swt-bamberg.de 12 Apr '10

12 Apr '10

Full_Name: Thomas Wunder Version: 2.4.17 OS: debian sqeueeze amd64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (141.13.106.69) Hi! I'm currently using the rwm overlay to filter the objects from my ou=students,dc=uni-bamberg,dc=de directory by their "o"-attribute and project the result to ou=students,ou=people,ou=swt,ou=wiai,dc=uni-bamberg,dc=de Therefore I use the following section within my slapd.conf (before the "database hdb..." section): database relay suffix "ou=students,ou=people,ou=swt,ou=wiai,dc=uni-bamberg,dc=de" overlay rwm #rwm-rewriteEngine on rwm-suffixmassage "ou=students,ou=people,ou=swt,ou=wiai,dc=uni-bamberg,dc=de" "ou=students,dc=uni-bamberg,dc=de" rwm-rewriteContext bindDN rwm-rewriteRule ".*" "cn=ldapadmin,dc=uni-bamberg,dc=de" ":@" rwm-rewriteContext searchFilter rwm-rewriteRule "(.*)" "(&(o=swt)$1)" ":@I" searchFilter rewriting works perfectly but I also need to rewrite the bindDN as every operation within ou=students,dc=uni-bamberg,dc=de needs to be carried out by a particular user (cn=ldapadmin,dc=uni-bamberg,dc=de) (the reason is that i don't want any user other than ldapadmin to be able to write ou=students,dc=uni-bamberg,dc=de but they should be able to modifiy entries within ou=students,ou=people,ou=swt,ou=wiai,dc=uni-bamberg,dc=de) according to the logs and the error reply messages there seems to be no binndn rewriting done... It looks like the rule never matches. Is my rule not general enough to match each possible bindDN-String? Is "cn=ldapadmin,dc=uni-bamberg,dc=de" (replacement string for the bindDN) not well formatted (does it expect something else)? Does the overlay "relay" prevent the replacement of the bindDN? As you can see I don't have any idea what might be causing my problem and I hope you can help me.

1 0

Re: (ITS#6503) syncrepl provider sends entryUUIDs of all LDAP records to consumer when consumer slapd is started
by hyc＠symas.com 12 Apr '10

12 Apr '10

bcolston(a)xtec.com wrote: > Provider slapd configuration (partial): > serverID 000 > database bdb > suffix "dc=authentx" > rootdn "SUPPRESSED" > rootpw SUPPRESSED > directory /authentx/db/ldap/authentx-sync1 > > overlay syncprov > syncprov-checkpoint 100 15 > syncprov-sessionlog 5000 This patch will probably work: diff -u -r1.309 syncprov.c --- syncprov.c 21 Jan 2010 12:33:21 -0000 1.309 +++ syncprov.c 12 Apr 2010 01:33:02 -0000 @@ -1878,7 +1878,7 @@ } /* Add any log records */ - if ( si->si_logs && op->o_tag != LDAP_REQ_ADD ) { + if ( si->si_logs ) { syncprov_add_slog( op ); } leave: ldap_pvt_thread_mutex_unlock( &si->si_resp_mutex ); But I have not tested it. The session log was originally only intended to record deletes, since they require the most work to find otherwise. Recording adds is just a shortcut since the original behavior works as designed. -- -- 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#6498) SLAPI functions missing
by hyc＠symas.com 12 Apr '10

12 Apr '10

maci(a)satgnu.net wrote: > Full_Name: Marcel Wysocki > Version: 2.4.21 > OS: GNU/Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (88.79.126.162) > > > I noticed that all of the SLAPI functions do manipulate LDAPMod** are missing. > from the fedora ds slapi-plugin.h: > there might be some more missing. most of it can be found in fedora ds's > modutils.c > should be worth porting to openldap Patches welcome. If you're suggesting a copy/paste from FedoraDS's code then the patch must be submitted by someone who has ownership rights on the Fedora code. -- -- 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#6483) [PATCH] Properly use #elif
by hyc＠symas.com 12 Apr '10

12 Apr '10

delphij(a)FreeBSD.org wrote: > Full_Name: Xin LI > Version: -HEAD > OS: FreeBSD/amd64 > URL: http://people.freebsd.org/~delphij/misc/openldap-elif.diff > Submission from: (NULL) (206.40.55.65) > > > OpenLDAP uses several #elif to test if a macro is being defined, which should be > spelled as #elif defined. > > Here is a patch against CVS -HEAD. > > Index: include/ac/regex.h > =================================================================== > RCS file: /repo/OpenLDAP/pkg/ldap/include/ac/regex.h,v > retrieving revision 1.20 > diff -u -p -u -p -r1.20 regex.h > --- include/ac/regex.h 21 Jan 2009 23:40:18 -0000 1.20 > +++ include/ac/regex.h 1 Mar 2010 20:12:52 -0000 > @@ -28,7 +28,7 @@ > */ > #error "No POSIX REGEX available." > > -#elif HAVE_GNUREGEX_H > +#elif defined(HAVE_GNUREGEX_H) > /* system has GNU gnuregex.h */ > # include<gnuregex.h> > #else That patch is incorrect. Autoconf HAVE_xx macros must be defined to 1 to actually be used, some scripts may also define them to 0. The current test is correct. Closing this ITS. -- -- 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#6488) Nssov updates for new versions of nss-pam-ldapd
by hyc＠symas.com 12 Apr '10

12 Apr '10

crispy(a)cluenet.org wrote: > Hi, any word on if this can be incorporated? Committed in HEAD, thanks for the patch. -- -- 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#6194) Patch - Enhancement - provide LDIF support as libldif
by masarati＠aero.polimi.it 12 Apr '10

12 Apr '10

>> >>> Sorry about that. You can find it here: >>> http://rmeggins.fedorapeople.org/ldifutil.c >> >> Gotit, thanks. I have one first comment: the public API does not >> generally expose the memory context. I'm renaming >> ldap_parse_ldif_record() as ldap_parse_ldif_record_x(), and eliminating >> the void *ctx arg from ldap_parse_ldif_record(), if you don't mind. > > tested and applied to HEAD; please test. Thanks, p. More comments: 1) perhaps it may be worth providing a function that converts a LDIFRecord structure into a string, and one that sends it to a stream 2) I note you put LDAPMod **lr_mods; /* list of mods for LDAP_REQ_MODIFY, LDAP_REQ_ADD */ struct berval lr_newrdn; /* LDAP_REQ_MODDN, LDAP_REQ_MODRDN, LDAP_REQ_RENAME */ struct berval lr_newsuperior; /* LDAP_REQ_MODDN, LDAP_REQ_MODRDN, LDAP_REQ_RENAME */ int lr_deleteoldrdn; /* LDAP_REQ_MODDN, LDAP_REQ_MODRDN, LDAP_REQ_RENAME */ /* the following are for future support */ struct berval lr_extop_oid; /* LDAP_REQ_EXTENDED */ struct berval lr_extop_data; /* LDAP_REQ_EXTENDED */ struct berval lr_cmp_attr; /* LDAP_REQ_COMPARE */ struct berval lr_cmp_bvalue; /* LDAP_REQ_COMPARE */ in the structure; the last four are not used right now. I think it would make sense to group struct members by op in substructures, and then put them in a union, to stress the fact that they're mutually exclusive. Much like Howard did for the corresponding substructures in the Operation struct in slapd. p.

1 0

Re: (ITS#6432) PATCH: MozNSS crypto (tls_m.c) - support InitContext, improved PEM support
by hyc＠symas.com 12 Apr '10

12 Apr '10

rmeggins(a)redhat.com wrote: > Any update on this? Sorry I must've missed your last reply, I thought we were still waiting on you. Why is pem_mod_name needed as an independent variable? Since it's const I presume it will not be changing in the future? (Not asking for a change here, just want to understand its purpose.) Actually, since it and pem_library are only used once each, I would probably just #define it instead. But again, just want to know first how constant it really is. I've committed the patch as-is. If any other tweaks are needed let us know. Thanks for working on this. -- -- 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#6194) Patch - Enhancement - provide LDIF support as libldif
by masarati＠aero.polimi.it 12 Apr '10

12 Apr '10

> >> Sorry about that. You can find it here: >> http://rmeggins.fedorapeople.org/ldifutil.c > > Gotit, thanks. I have one first comment: the public API does not > generally expose the memory context. I'm renaming > ldap_parse_ldif_record() as ldap_parse_ldif_record_x(), and eliminating > the void *ctx arg from ldap_parse_ldif_record(), if you don't mind. tested and applied to HEAD; please test. Thanks, p.

1 0

Re: (ITS#6194) Patch - Enhancement - provide LDIF support as libldif
by masarati＠aero.polimi.it 11 Apr '10

11 Apr '10

> Sorry about that. You can find it here: > http://rmeggins.fedorapeople.org/ldifutil.c Gotit, thanks. I have one first comment: the public API does not generally expose the memory context. I'm renaming ldap_parse_ldif_record() as ldap_parse_ldif_record_x(), and eliminating the void *ctx arg from ldap_parse_ldif_record(), if you don't mind. p.

1 0

Re: (ITS#6194) Patch - Enhancement - provide LDIF support as libldif
by richm＠stanfordalumni.org 11 Apr '10

11 Apr '10

On Sun, Apr 11, 2010 at 10:07 AM, <masarati(a)aero.polimi.it> wrote: >> 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= -20100409.patch > > Rich, > > ldifutil.c seems to be missing in that file. =A0Can you provide it? =A0Ei= ther > a separate file, or a new version of the patch is fine. Sorry about that. You can find it here: http://rmeggins.fedorapeople.org/ldifutil.c > > Thanks, p. > > >> 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. =A0This >> 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. >> >> =A0 =A0 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. >> >> =A0 =A0 Red Hat, Inc. hereby place the following modifications to OpenLD= AP >> 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#6513) dynacl/aci fails on searches with attributes
by masarati＠aero.polimi.it 11 Apr '10

11 Apr '10

> Full_Name: Peter Marschall > Version: 2.4.21 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/Peter-Marschall-100411.patch > Submission from: (NULL) (94.217.135.20) > > > Hi, > > Playing around with dynacl/aci a bit I cam across the following issue: > > Searches that do not contain the attribute OpenLDAPaci in the list of > attribues > queried, omit objects. dynacl/aci (as the original aci code it's based on) relies on the fact that the entry is complete. This is the case when the entry is stored locally, e.g. in back-bdb/hdb. Otherwise, no mechanism is in place to retrieve operational attributes. Please note that in the latter case, even ACL rules based on, say, createTimestamp or so would operate incorrectly. My guess is that you're trying to use ACIs with a non-local storage. In that case your analysis is correct. Can you provide your (sanitized) configuration? The "right" solution is much more general, not only related to dynacl. Slapd needs to know in advance what (operational) attributes are required for policy enforcing, and they need to be added to requested attrs when entries are collected from remote storage. Your patch seems to fix your specific need, but it is clearly inefficient. p.

1 0

(ITS#6513) dynacl/aci fails on searches with attributes
by peter＠adpm.de 11 Apr '10

11 Apr '10

Full_Name: Peter Marschall Version: 2.4.21 OS: Linux URL: ftp://ftp.openldap.org/incoming/Peter-Marschall-100411.patch Submission from: (NULL) (94.217.135.20) Hi, Playing around with dynacl/aci a bit I cam across the following issue: Searches that do not contain the attribute OpenLDAPaci in the list of attribues queried, omit objects. E.g. doing a base search for 1.1 on an object that has the following OpenDLAPaci value OpenLDAPaci: 0#entry#grant;r,c,s,d,x;[entry]#public# OpenLDAPaci: 0#entry#grant;r,c,s,d,x;[all]#public# (no superior object has a subtree OpenLDAPaci) does not return the DN of the object, while doing the search without arguments returns the DN. According to my experiments, it looks like the Entry *e passed as argument to dynacl_aci_mask() does not have OpenLDAPaci in its e->e_attrs. I wrote the patch ftp://ftp.openldap.org/incoming/Peter-Marschall-100411.patch to verify my suspicions, and it seems to help, although at the cost of abysmally bad performance. I guess there are better ways to fix the issue (e.g. "auto-adding" OpenLDAPaci to the attributes queried from the backend and stripping it before giving it back to the client), but my knowledge of the internal workings of OpenLDAP is too limited.

1 0

Re: (ITS#6194) Patch - Enhancement - provide LDIF support as libldif
by masarati＠aero.polimi.it 11 Apr '10

11 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… Rich, ldifutil.c seems to be missing in that file. Can you provide it? Either a separate file, or a new version of the patch is fine. Thanks, p. > 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#6512) configure error - BerkeleyDB 5.0 problem?
by patrice.moreaux＠univ-savoie.fr 10 Apr '10

10 Apr '10

Dear Quanah, Thank you very much for your so fast answer. > OpenLDAP has not yet been tested with BDB 5.0. Ok, so I will use the 4.x last version of BDB. I think that in the configure script, the major version number of BDB is more or less "hard coded" as "4". This could perhaps help your team! bets regards Patrice ______________________________________________________ Patrice Moreaux, Professor email: patrice.moreaux(a)univ-savoie.fr LISTIC - Polytech Annecy-Chambéry - University of Savoie BP 80439, 74944 Annecy le Vieux Cedex, France. Phone: (+33/0) 450 096 524 - Fax: (+33/0) 450 096 559 ______________________________________________________

1 0

Re: (ITS#6512) configure error - BerkeleyDB 5.0 problem?
by patrice.moreaux＠univ-savoie.fr 10 Apr '10

10 Apr '10

Dear Howard, Thank you very much for your answer. > quanah(a)zimbra.com wrote: >> --On Friday, April 09, 2010 11:25 PM +0000 patrice.moreaux(a)univ-savoie.fr >>> Submission from: (NULL) (193.48.130.254) >> OpenLDAP has not yet been tested with BDB 5.0. >> --Quanah > > The ITS is for legitimate bug reports, not help requests. There's no > reason OpenLDAP won't work with BDB 5.0, but this question belongs on > the -software mailing list, not the ITS. Please, excuse me for my mistake. I am in fact a new user of the OpenLDAP server. I will post on the software mailing list. Please also note that I have erroneously posted a new item in the FAQ! It will be fine is somebody of the OpenLDAP staff could discard it. Best regards, Patrice Moreaux ______________________________________________________ Patrice Moreaux, Professor email: patrice.moreaux(a)univ-savoie.fr LISTIC - Polytech Annecy-Chambéry - University of Savoie BP 80439, 74944 Annecy le Vieux Cedex, France. Phone: (+33/0) 450 096 524 - Fax: (+33/0) 450 096 559 ______________________________________________________

1 0

Re: (ITS#6512) configure error - BerkeleyDB 5.0 problem?
by hyc＠symas.com 10 Apr '10

10 Apr '10

quanah(a)zimbra.com wrote: > --On Friday, April 09, 2010 11:25 PM +0000 patrice.moreaux(a)univ-savoie.fr > wrote: > >> Full_Name: Patrice Moreaux >> Version: 2.4.21 >> OS: Ubuntu Lucid server 32bits >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (193.48.130.254) > > OpenLDAP has not yet been tested with BDB 5.0. > > --Quanah The ITS is for legitimate bug reports, not help requests. There's no reason OpenLDAP won't work with BDB 5.0, but this question belongs on the -software mailing list, not the ITS. -- -- 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#6478) slapd crashes with segfault
by masarati＠aero.polimi.it 10 Apr '10

10 Apr '10

> We managed to install it with debug-symbols now, > but did not have a new crash (yet). > > However we did a deeper anaylysis of existing > crashes. > Here is the outcome: [snip] > (gdb) thread 1 > [Switching to thread 1 (process 17895)]#0 0x00000037a4e30045 in raise () > f= > rom /lib64/libc.so.6 > (gdb) bt > #0 0x00000037a4e30045 in raise () from /lib64/libc.so.6 > #1 0x00000037a4e31ae0 in abort () from /lib64/libc.so.6 > #2 0x00000037a4e681bb in __libc_message () from /lib64/libc.so.6 > #3 0x00000037a4e6f444 in _int_free () from /lib64/libc.so.6 > #4 0x00000037a4e72a6c in free () from /lib64/libc.so.6 > #5 0x0000000000559e07 in sb_rdahead_remove (sbiod=3D0x2aaac488d0d0) at > ../= > ../../libraries/liblber/sockbuf.c:606 I still see some inconsistencies: in sockbuf.c there's no call to free() at line 606. So, either the core is inconsistent, or slapd was linking an incorrect liblber, if at all possible. Not sure how to proceeding in debugging this issue. p.

1 0

Re: (ITS#6512) configure error - BerkeleyDB 5.0 problem?
by quanah＠zimbra.com 10 Apr '10

10 Apr '10

--On Friday, April 09, 2010 11:25 PM +0000 patrice.moreaux(a)univ-savoie.fr wrote: > Full_Name: Patrice Moreaux > Version: 2.4.21 > OS: Ubuntu Lucid server 32bits > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.48.130.254) OpenLDAP has not yet been tested with BDB 5.0. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6512) configure error - BerkeleyDB 5.0 problem?
by patrice.moreaux＠univ-savoie.fr 10 Apr '10

10 Apr '10

Full_Name: Patrice Moreaux Version: 2.4.21 OS: Ubuntu Lucid server 32bits URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.48.130.254) Date: 2010/04/06 I installed BerkeleyDB 5.0. Running configure for OpenLDAP 2.4.21 1. BDB 5.0 header is correcty read (major=5, minor=0) 2. However I got then: -------------------------------------------------------- checking if BerkeleyDB version supported by BDB/HDB backends... yes checking for BerkeleyBD link (default)... no configure: error: BDB/HDB: BerkeleyDB not available -------------------------------------------------------- I set the paths for libs and includes. I don't know where is the problem. Could you help me, please? Thank you, regards.

1 0

Re: (ITS#6244) "now" dynacl module
by masarati＠aero.polimi.it 10 Apr '10

10 Apr '10

I've uploaded a README with a simple example. <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-09-README.now> p.

1 0

Re: (ITS#6456) Feature Request
by masarati＠aero.polimi.it 09 Apr '10

09 Apr '10

> Full_Name: J > Version: 2.4.20 > OS: Debian-Lenny/amd64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (68.15.14.98) > > > Greetings, > > Having found out this doesn't already exist as another parameter or > configuration method, I am hereby submitting a request for a particular > feature. > > When performing idassert-bind operations, such as with back_ldap, it would > be > great if an option could be added which would allow specific matched > client DNs > to be matched and asserted as usual (e.g: the anonymous user asserting to > a > backend "proxyauthenticator" account) .... while other clients (flagged > somehow) > would pass-through as themselves. > > Example (as I might do it for my purposes): > > idassert-bind > bindmethod="simple" > binddn="uid=proxyauthenticator,ou=users,dc=example,dc=com" > credentials="password_string" > starttls="yes" > tls_reqcert="never" > mode="none" > > # anonymous clients will assert as "proxyauthenticator", since the backend > may > not allow anonymous binds. > idassert-authzFrom "dn.exact:" > > # this guy will pass through as himself to the backend, as-is. > idassert-passThrough "dn.exact:uid=admin,ou=users,dc=example,dc=com" > > This would be really helpful, not sure if its difficult to implement ... This is now implemented in back-ldap (idassert-passthru, olcDbIDAssertPassThru, undocumented yet). Basically, identities matching rules formally identical to those of idassert-authzFrom do not undergo identity assertion. This rule is checked before idassert-authzFrom, so in case an identity matches both, passthru wins. Please test and report. p.

1 0

Re: (ITS#6194) Patch - Enhancement - provide LDIF support as libldif
by masarati＠aero.polimi.it 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. Kurt, if you give IPR clearance I can start (evaluating and) integrating this. p.

1 0

Re: (ITS#6432) PATCH: MozNSS crypto (tls_m.c) - support InitContext, improved PEM support
by rmeggins＠redhat.com 09 Apr '10

09 Apr '10

Any update on this?

1 0

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 09 Apr '10

09 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 09 Apr '10

09 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 09 Apr '10

09 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 09 Apr '10

09 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

Re: (ITS#6507) backglue and paged results issue
by jonathan＠phillipoux.net 08 Apr '10

08 Apr '10

Le 08/04/2010 15:59, masarati(a)aero.polimi.it a écrit : >> Just one weird case left. Considering the same setup as described above >> (back null with 2 back ldap glued underneath): a search with pagedResults >> and a page size of 3 (the exact number of results returned by each back >> ldap), we get: >> - a first page with the 3 results from back ldap 1 >> - a second page with 3 results from back ldap 2 (so far, so good) >> - but then this last result also has a pagedResults cookie, and the search >> can go on and on, returning the same 2nd page. >> >> Presumably this is related to the patch allowing pagedResults to cross two >> databases. If the first returns an empty cookie (no more results), a new >> cookie is added. However, this should not be done if the last database >> returns no more results. > > It's related to the fact that I need to parse the cookie when it's not > parsed yet, to see whether it's empty. So I'm now parsing it also when > working with the last database, which needs to be treated specially (i.e. > it must let the empty cookie pss thru). Fixed, will commit in a moment. > > Thanks, p. 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? Jonathan -- -------------------------------------------------------------- Jonathan Clarke - jonathan(a)phillipoux.net -------------------------------------------------------------- Ldap Synchronization Connector (LSC) - http://lsc-project.org --------------------------------------------------------------

1 0

Re: (ITS#6507) backglue and paged results issue
by masarati＠aero.polimi.it 08 Apr '10

08 Apr '10

> This is a multi-part message in MIME format. > --------------050800080103050407050909 > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > Content-Transfer-Encoding: 8bit > > Le 08/04/2010 13:49, jonathan(a)phillipoux.net a écrit : >> On Wed, 7 Apr 2010 00:54:46 +0200 (CEST), masarati(a)aero.polimi.it wrote: >>>> Le 06/04/2010 20:55, masarati(a)aero.polimi.it a Ã©crit : >>>>> When requesting paged results control on glued databases, if a >>>>> database >>>>> (either >>>>> superior or subordinate) returns one page that ends with the last >>>>> corresponding >>>>> entry in that database, the resulting cookie is empty. Thus, the >> result >>>>> returned to the client corresponds to the final result of a paged >>>>> response. >>>>> However, other databases may have returned data. A fix is being >>>>> designed. p. >>>> >>>> Your fix for this problem works well in my tests. >>>> >>>> Under the same subject, another problem arises: >>>> >>>> Consider this : >>>> - back null >>>> ---- back ldap 1 returning 3 results to a search >>>> ---- back ldap 2 returning 3 results to a search >>>> >>>> And you search "back null" with a page size of 2: >>>> - The first response contains 2 results from "back ldap 1" and a >>>> correct >>>> cookie. >>>> - The second response contains 1 result from "back ldap 1" and 1 >>>> result >>>> from "back ldap 2", and another correct cookie. >>>> - The third request, however, goes back to "back ldap 1", and returns >>>> the same results as the first response. >>>> - And so on... forever. >>>> >>>> As I mentioned, it seems that to solve this problem we would have to >>>> tie >>>> a paged results cookie to a particular backend under glue... >>> >>> Should work now. The issue was related to the fact that unless the >>> subordinate backends are local, the response to pgaed results has not >> been >>> parsed into the connection structure... >> >> Yes, much better now. >> >> Just one weird case left. Considering the same setup as described above >> (back null with 2 back ldap glued underneath): a search with >> pagedResults >> and a page size of 3 (the exact number of results returned by each back >> ldap), we get: >> - a first page with the 3 results from back ldap 1 >> - a second page with 3 results from back ldap 2 (so far, so good) >> - but then this last result also has a pagedResults cookie, and the >> search >> can go on and on, returning the same 2nd page. >> >> Presumably this is related to the patch allowing pagedResults to cross >> two >> databases. If the first returns an empty cookie (no more results), a new >> cookie is added. However, this should not be done if the last database >> returns no more results. > > It seems it just needs a simple exception for the last database. The > attached patch works for me. > > Jonathan > -- > -------------------------------------------------------------- > Jonathan Clarke - jonathan(a)phillipoux.net > -------------------------------------------------------------- > Ldap Synchronization Connector (LSC) - http://lsc-project.org > -------------------------------------------------------------- > > --------------050800080103050407050909 > Content-Type: text/x-patch; > name="jcl-backglue-20100408.patch" > Content-Transfer-Encoding: 7bit > Content-Disposition: attachment; > filename="jcl-backglue-20100408.patch" > > Index: servers/slapd/backglue.c > =================================================================== > RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/backglue.c,v > retrieving revision 1.153 > diff -a -u -r1.153 backglue.c > --- servers/slapd/backglue.c 6 Apr 2010 20:04:58 -0000 1.153 > +++ servers/slapd/backglue.c 8 Apr 2010 15:39:34 -0000 > @@ -559,6 +559,7 @@ > > /* Check whether the cookie is empty, > * and give remaining databases a chance > + * unless this is already the last database > */ > if ( op->o_bd != gi->gi_n[0].gn_be ) { > int c; > @@ -581,7 +582,7 @@ > tag = ber_scanf( ber, "{im}", &size, &cookie ); > assert( tag != LBER_ERROR ); > > - if ( BER_BVISEMPTY( &cookie ) ) { > + if ( BER_BVISEMPTY( &cookie ) && i != 0 ) { > if ( btmp == b0 ) { > op->o_conn->c_pagedresults_state.ps_be = gi->gi_n[gi->gi_nodes > - 1].gn_be; Yes, thanks. I already fixed it almost the same way. p.

1 0

Re: (ITS#6507) backglue and paged results issue
by jonathan＠phillipoux.net 08 Apr '10

08 Apr '10

This is a multi-part message in MIME format. --------------050800080103050407050909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Le 08/04/2010 13:49, jonathan(a)phillipoux.net a écrit : > On Wed, 7 Apr 2010 00:54:46 +0200 (CEST), masarati(a)aero.polimi.it wrote: >>> Le 06/04/2010 20:55, masarati(a)aero.polimi.it a Ã©crit : >>>> When requesting paged results control on glued databases, if a database >>>> (either >>>> superior or subordinate) returns one page that ends with the last >>>> corresponding >>>> entry in that database, the resulting cookie is empty. Thus, the > result >>>> returned to the client corresponds to the final result of a paged >>>> response. >>>> However, other databases may have returned data. A fix is being >>>> designed. p. >>> >>> Your fix for this problem works well in my tests. >>> >>> Under the same subject, another problem arises: >>> >>> Consider this : >>> - back null >>> ---- back ldap 1 returning 3 results to a search >>> ---- back ldap 2 returning 3 results to a search >>> >>> And you search "back null" with a page size of 2: >>> - The first response contains 2 results from "back ldap 1" and a correct >>> cookie. >>> - The second response contains 1 result from "back ldap 1" and 1 result >>> from "back ldap 2", and another correct cookie. >>> - The third request, however, goes back to "back ldap 1", and returns >>> the same results as the first response. >>> - And so on... forever. >>> >>> As I mentioned, it seems that to solve this problem we would have to tie >>> a paged results cookie to a particular backend under glue... >> >> Should work now. The issue was related to the fact that unless the >> subordinate backends are local, the response to pgaed results has not > been >> parsed into the connection structure... > > Yes, much better now. > > Just one weird case left. Considering the same setup as described above > (back null with 2 back ldap glued underneath): a search with pagedResults > and a page size of 3 (the exact number of results returned by each back > ldap), we get: > - a first page with the 3 results from back ldap 1 > - a second page with 3 results from back ldap 2 (so far, so good) > - but then this last result also has a pagedResults cookie, and the search > can go on and on, returning the same 2nd page. > > Presumably this is related to the patch allowing pagedResults to cross two > databases. If the first returns an empty cookie (no more results), a new > cookie is added. However, this should not be done if the last database > returns no more results. It seems it just needs a simple exception for the last database. The attached patch works for me. Jonathan -- -------------------------------------------------------------- Jonathan Clarke - jonathan(a)phillipoux.net -------------------------------------------------------------- Ldap Synchronization Connector (LSC) - http://lsc-project.org -------------------------------------------------------------- --------------050800080103050407050909 Content-Type: text/x-patch; name="jcl-backglue-20100408.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="jcl-backglue-20100408.patch" Index: servers/slapd/backglue.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/backglue.c,v retrieving revision 1.153 diff -a -u -r1.153 backglue.c --- servers/slapd/backglue.c 6 Apr 2010 20:04:58 -0000 1.153 +++ servers/slapd/backglue.c 8 Apr 2010 15:39:34 -0000 @@ -559,6 +559,7 @@ /* Check whether the cookie is empty, * and give remaining databases a chance + * unless this is already the last database */ if ( op->o_bd != gi->gi_n[0].gn_be ) { int c; @@ -581,7 +582,7 @@ tag = ber_scanf( ber, "{im}", &size, &cookie ); assert( tag != LBER_ERROR ); - if ( BER_BVISEMPTY( &cookie ) ) { + if ( BER_BVISEMPTY( &cookie ) && i != 0 ) { if ( btmp == b0 ) { op->o_conn->c_pagedresults_state.ps_be = gi->gi_n[gi->gi_nodes - 1].gn_be; --------------050800080103050407050909--

1 0

Re: (ITS#6508) memberof segmentation fault
by masarati＠aero.polimi.it 08 Apr '10

08 Apr '10

Fixed in HEAD; please check. a_numvals was added in September 2007 (slap.h 1.831 Fri Sep 21 06:43:56 2007); slapo-memberof.c was first committed in August 2007 (memberof.c 1.1 Fri Aug 24 00:46:58 2007), but developed about one year earlier. I'm surprised it survived so long without the a_numvals bit :) Thanks, p.

1 0

Re: (ITS#6507) backglue and paged results issue
by masarati＠aero.polimi.it 08 Apr '10

08 Apr '10

> Just one weird case left. Considering the same setup as described above > (back null with 2 back ldap glued underneath): a search with pagedResults > and a page size of 3 (the exact number of results returned by each back > ldap), we get: > - a first page with the 3 results from back ldap 1 > - a second page with 3 results from back ldap 2 (so far, so good) > - but then this last result also has a pagedResults cookie, and the search > can go on and on, returning the same 2nd page. > > Presumably this is related to the patch allowing pagedResults to cross two > databases. If the first returns an empty cookie (no more results), a new > cookie is added. However, this should not be done if the last database > returns no more results. It's related to the fact that I need to parse the cookie when it's not parsed yet, to see whether it's empty. So I'm now parsing it also when working with the last database, which needs to be treated specially (i.e. it must let the empty cookie pss thru). Fixed, will commit in a moment. Thanks, p.

1 0

(ITS#6510) GSSAPI rebind proc will cause mutex deadlock
by inlovewithGod＠gmail.com 08 Apr '10

08 Apr '10

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. Thanks, - Jeremiah

1 0

Re: (ITS#6507) backglue and paged results issue
by jonathan＠phillipoux.net 08 Apr '10

08 Apr '10

On Wed, 7 Apr 2010 00:54:46 +0200 (CEST), masarati(a)aero.polimi.it wrote: >> Le 06/04/2010 20:55, masarati(a)aero.polimi.it a écrit : >>> When requesting paged results control on glued databases, if a database >>> (either >>> superior or subordinate) returns one page that ends with the last >>> corresponding >>> entry in that database, the resulting cookie is empty. Thus, the result >>> returned to the client corresponds to the final result of a paged >>> response. >>> However, other databases may have returned data. A fix is being >>> designed. p. >> >> Your fix for this problem works well in my tests. >> >> Under the same subject, another problem arises: >> >> Consider this : >> - back null >> ---- back ldap 1 returning 3 results to a search >> ---- back ldap 2 returning 3 results to a search >> >> And you search "back null" with a page size of 2: >> - The first response contains 2 results from "back ldap 1" and a correct >> cookie. >> - The second response contains 1 result from "back ldap 1" and 1 result >> from "back ldap 2", and another correct cookie. >> - The third request, however, goes back to "back ldap 1", and returns >> the same results as the first response. >> - And so on... forever. >> >> As I mentioned, it seems that to solve this problem we would have to tie >> a paged results cookie to a particular backend under glue... > > Should work now. The issue was related to the fact that unless the > subordinate backends are local, the response to pgaed results has not been > parsed into the connection structure... Yes, much better now. Just one weird case left. Considering the same setup as described above (back null with 2 back ldap glued underneath): a search with pagedResults and a page size of 3 (the exact number of results returned by each back ldap), we get: - a first page with the 3 results from back ldap 1 - a second page with 3 results from back ldap 2 (so far, so good) - but then this last result also has a pagedResults cookie, and the search can go on and on, returning the same 2nd page. Presumably this is related to the patch allowing pagedResults to cross two databases. If the first returns an empty cookie (no more results), a new cookie is added. However, this should not be done if the last database returns no more results. Jonathan

1 0

(ITS#6509) slapo-memberof follow cascading group membership
by sspreitzer＠ch.ibm.com 08 Apr '10

08 Apr '10

Full_Name: Sascha Thomas Spreitzer Version: 2.4.21 OS: Linux RHEL 5.4 ppc64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.212.29.179) Dear openldap developers and maintainers of the memberof feature, it would be great if you could implement a cascading group membership functionality. Like say a group can be part of a group and those members will be listed respectively. Thank you very much in advance, yours sincerely, Sascha Thomas Spreitzer IBM Switzerland - unix engineering Fedora Project Ambassador

1 0

TLS issues
by Daniel Gomes 08 Apr '10

08 Apr '10

Dear list members, I am having some problems with TLS I would like to share and hopefully solve with your help. First of all, the specs: it's a OpenLDAP 2.4.19 compiled (manually, not via apt-get) on a Ubuntu 8.04 (Hardy). I don't think it matters, but I am using the dynlist overlay (that's why I had to compile manually and not via apt-get, as I couldn't get it to work with the package Ubuntu provides). Passing on to the problem itself, let me just start by saying that the SSL/TLS setup itself seems to be working fine, and I am always able to ldapsearch on port 636 with ldaps:// (SSL) or on port 389 with ldap:// and -ZZ (TLS). Unfortunately, using other clients (phpLDAPadmin and some custom php scripts I wrote), the behavior is rather random. Sometimes it fails, sometimes it works (at the beginning it worked more often than not, lately it has been working less and less). The server logs, unfortunately, are not so helpful (for me, at least!). The only error I see (with logs at -1, trying to connect via phpLDAPadmin with TLS on port 389) is: connection_read(15): TLS accept failure error=-1 id=23, closing Apr 7 16:45:18 gold slapd[7385]: connection_closing: readying conn=23 sd=15 for close Apr 7 16:45:18 gold slapd[7385]: connection_close: conn=23 sd=15 Apr 7 16:45:18 gold slapd[7385]: daemon: removing 15 Apr 7 16:45:18 gold slapd[7385]: daemon: activity on 1 descriptor Apr 7 16:45:18 gold slapd[7385]: daemon: activity on: Apr 7 16:45:18 gold slapd[7385]: conn=23 fd=15 closed (TLS negotiation failure) Trying on port 636 with ldaps:// yields the same error. But as I mentioned, it just happen sometimes, while on others the connection is successfully established! Although I did notice that even when it does work, I get the following error: connection_read(14): unable to get TLS client DN, error=49 id=8 but it is quickly followed by a "conn=8 fd=14 TLS established tls_ssf=256 ssf=256"... So, this is my problem and it is getting me quite puzzled... The fact that it does work on occasion makes me think it can't be my configuration or the usual file permission culprit... Here's my slapd.conf (I removed the ACL configuration, as I am guessing it's not important here): # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/dyngroup.schema include /usr/local/etc/openldap/schema/inetorgperson.schema #Custom Schemas include /usr/local/etc/openldap/schema/local.schema include /usr/local/etc/openldap/schema/postfix.schema pidfile /home/slapd/run/slapd.pid argsfile /home/slapd/run/slapd.args ####################################################################### # Database definitions ####################################################################### database hdb suffix "dc=example,dc=com" rootdn "cn=admin,dc=example,dc=com" rootpw secret directory /home/slapd/database index objectClass eq ####################################################################### # Replication ####################################################################### overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 ####################################################################### # TLS ####################################################################### TLSCipherSuite HIGH:MEDIUM:+SSLv2 TLSCACertificateFile /home/slapd/ssl/cacert.pem TLSCertificateFile /home/slapd/ssl/servercrt.pem TLSCertificateKeyFile /home/slapd/ssl/serverkey.pem TLSVerifyClient never ####################################################################### # Overlay (for dynamic lists) ####################################################################### overlay dynlist dynlist-attrset ipfnRole memberURL member If it helps for anything, in the ldap.conf files of the client I also have the "TLS_REQCERT never" setting, together with the TLS_CACERT and TLS_CACERTDIR for the CA's certificate. Thanks in advance for any help, -- Daniel Gomes (SysAdmin) dgomes(a)ipfn.ist.utl.pt Ext. 3487 - 218419487 Instituto de Plasmas e usão Nuclear Instituto Superior Técnico - UTL Av. Rovisco Pais - 1049-001 Lisboa - Portugal

2 1

(ITS#6508) memberof segmentation fault
by ndunbar＠llnw.com 08 Apr '10

08 Apr '10

Full_Name: Neil Dunbar Version: 2.4.21 OS: Debian 5, Ubuntu 9.10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (68.142.115.87) Hi there, It looks like there's a small bug in memberof.c - it only manifests itself when "memberof_dangling" is set to "drop". I think that, while the overlay reduces the a->a_vals and a->a_nvals array by one, to strip out a non-existent DN, it needs to reduce the a->a_numvals variable as well. The end result of this is that if one adds a group which has a mix of members which exist in the DIT, and some which don't, the entry_encode() routing will segfault. [I can only reproduce the segv in back-bdb and back-hdb. back-ldif doesn't seem to exhibit this behaviour]. I've uploaded a tiny slapd.conf and test LDIF file (in ftp://ftp.openldap.org/incoming/memberof-segv-20100407.tar.gz) which is normally enough to trigger the fault. If one starts up slapd via slapd -f mof-slapd.conf -h ldap://localhost -d trace followed by ldapmodify -x -H ldap://localhost -D cn=admin,dc=test -w adminpw -f ldif/test-memberof.ldif one should see an assertion fail in entry_encode() with (i == a->a_numvals) failing. The following patch seems to fix it, but I haven't done real regression testing to see if it rolls other errors. The normal slapd unit tests seem to yield proper results though. ---8<----8<------ --- memberof.c.orig 2010-04-07 16:49:44.000000000 -0700 +++ memberof.c 2010-04-07 16:49:20.000000000 -0700 @@ -580,6 +580,7 @@ sizeof( struct berval ) * ( j - i ) ); } i--; + a->a_numvals--; } } ---8<----8<------ Hope this helps, Neil

1 0

Re: (ITS#6507) backglue and paged results issue
by masarati＠aero.polimi.it 07 Apr '10

07 Apr '10

> Le 06/04/2010 20:55, masarati(a)aero.polimi.it a écrit : >> When requesting paged results control on glued databases, if a database >> (either >> superior or subordinate) returns one page that ends with the last >> corresponding >> entry in that database, the resulting cookie is empty. Thus, the result >> returned to the client corresponds to the final result of a paged >> response. >> However, other databases may have returned data. A fix is being >> designed. p. > > Your fix for this problem works well in my tests. > > Under the same subject, another problem arises: > > Consider this : > - back null > ---- back ldap 1 returning 3 results to a search > ---- back ldap 2 returning 3 results to a search > > And you search "back null" with a page size of 2: > - The first response contains 2 results from "back ldap 1" and a correct > cookie. > - The second response contains 1 result from "back ldap 1" and 1 result > from "back ldap 2", and another correct cookie. > - The third request, however, goes back to "back ldap 1", and returns > the same results as the first response. > - And so on... forever. > > As I mentioned, it seems that to solve this problem we would have to tie > a paged results cookie to a particular backend under glue... Should work now. The issue was related to the fact that unless the subordinate backends are local, the response to pgaed results has not been parsed into the connection structure... p.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs