- openldap-bugs - openldap.org

Re: (ITS#5942) URI matching of "self" in add_syncrepl is incomplete
by hyc＠symas.com 12 Feb '09

12 Feb '09

Howard Chu wrote: > hyc(a)symas.com wrote: >> jclarke(a)linagora.com wrote: >>> I saw the comment in the code that clarifies this behaviour. However, it's a >>> surprising behaviour, and I think there is code to parse this kind of thing in >>> the serverID detection now. Maybe it could be reused? > > Oops, never mind. I was thinking of the serverID code, and you're talking > about the syncrepl code. > > I'll have to think a bit about why the two aren't behaving identically; > probably they should both use the same code. > Ah right. For the serverID code, we're doing a liberal match because anything that matches the current name:port is obviously the current server, and we want it to be identified as such. For syncrepl, we know full well that it may be the current server, but for whatever reason you may want to replicate against yourself anyway (e.g., against a different baseDN, etc...). -- -- 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#5942) URI matching of "self" in add_syncrepl is incomplete
by hyc＠symas.com 12 Feb '09

12 Feb '09

hyc(a)symas.com wrote: > jclarke(a)linagora.com wrote: >> Full_Name: Jonathan Clarke >> Version: RE24 >> OS: irrelevant >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (213.41.243.192) >> >> >> Hi, >> >> When adding a syncrepl config, the function add_syncrepl performs a "check if >> URL points to current server". This check is based on an exact match between the >> provider parameter from the syncrepl config line, and the URIs given to slapd on >> startup. >> >> If this doesn't match when it should, the database is marked as a shadow, and >> all following updates fail with "shadow context; no update refs". This is quite >> a pain when it happens on cn=config :) >> >> There are multiple cases when this happens: >> 1) If no specific URI was specified on launch (no -h option) >> 2) Port numbers are explicitly specified or not (":389") >> 3) Trailing slash (for example "ldap://1.2.3.4" != "ldap://1.2.3.4/") >> 4) IP is specified rather than DNS name ("ldap://localhost" != >> "ldap://127.0.0.1") >> >> I saw the comment in the code that clarifies this behaviour. However, it's a >> surprising behaviour, and I think there is code to parse this kind of thing in >> the serverID detection now. Maybe it could be reused? Oops, never mind. I was thinking of the serverID code, and you're talking about the syncrepl code. I'll have to think a bit about why the two aren't behaving identically; probably they should both use the same 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#5942) URI matching of "self" in add_syncrepl is incomplete
by hyc＠symas.com 12 Feb '09

12 Feb '09

jclarke(a)linagora.com wrote: > Full_Name: Jonathan Clarke > Version: RE24 > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (213.41.243.192) > > > Hi, > > When adding a syncrepl config, the function add_syncrepl performs a "check if > URL points to current server". This check is based on an exact match between the > provider parameter from the syncrepl config line, and the URIs given to slapd on > startup. > > If this doesn't match when it should, the database is marked as a shadow, and > all following updates fail with "shadow context; no update refs". This is quite > a pain when it happens on cn=config :) > > There are multiple cases when this happens: > 1) If no specific URI was specified on launch (no -h option) > 2) Port numbers are explicitly specified or not (":389") > 3) Trailing slash (for example "ldap://1.2.3.4" != "ldap://1.2.3.4/") > 4) IP is specified rather than DNS name ("ldap://localhost" != > "ldap://127.0.0.1") > > I saw the comment in the code that clarifies this behaviour. However, it's a > surprising behaviour, and I think there is code to parse this kind of thing in > the serverID detection now. Maybe it could be reused? > > Otherwise, we should probably document this behaviour, to avoid headaches :) The manpage says the serverID URL must use an FQDN. We already do a number of guesses in the code, I don't see any reason to extend this further. 1) with no URI the listener will default to localhost. The serverID URL should therefore refer to localhost, or omit the hostname. 2) Port numbers shouldn't be an issue, since they're always matched in the parsed URLs. 3) Trailing slashes don't matter in the parsed URLs. 4) The doc is quite explicit about using FQDN. I have no sympathy for people who trip over 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#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by philippe.eychart＠informatique.gov.pf 12 Feb '09

12 Feb '09

In fact, none of the LDAP clients need (can) write the directory servers. They (remote servers) only read informations needed to make (or upgrade) their own config files and to authenticate their own users. Client interfaces (web/php) allow the users to upgrade (or, according their profile, simply consult) the informations needed. Some of them (authorized "administrators" on remote sites) can to upgrade some more sensible informations (create/delete new users in their department, change them from groups, affect profile application softwares, create new emails/alias or proxy acces, upgrade departement informations or sometime, why not, administrate some new samba shares, ...) On central site, technicians of the hot-line or system administrators make the rest ... (of course, everything is not totally ended and work remains to be done ... What, as matter of fact, remains a good think concerning my remuneration ;-) --- PE -----Message d'origine----- De : Michael Ströder [mailto:michael@stroeder.com] Envoyé : jeudi 12 février 2009 00:29 À : Philippe EYCHART Cc : openldap-its(a)openldap.org Objet : Re: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine) Philippe EYCHART wrote: > philippe.eychart(a)informatique.gov.pf wrote: >> Used of SRV rr is a good reponse, (in particular in case of large Intranet >> with many >> remote sites -islands in pacific- and poor communication ressources - >> satellite) but require >> to be performed in all client applications : nssldap, samba, ldap client >> tools >> for rsync/mail/DNS/proxy/supervision definitions, ... or openldap. > > We are in this case : I work in Tahiti, for the french polynesian > gouvernment, IT departement. > Our intranet take in a big geographic area recovering several islands. > I'm in charge to transfer of the totality of our management systems (and > network config) in a centralized base (of course: openldap). > But, in one hand, distant servers (and users) can't be submit to > communication links quality, in particular concerning local services > (authentifications, local messaging, samba service, etc ...) and in other > hand, we can't multipy the number of ldap servers assuming redundence (quite > services merged, we already manage more than 100 servers - and about 4000 > pc). > So, one local server in every remote site must assume ldap service for the > other local servers (which assume different services for different > administrative departements) to guarantee acceptable performances (and also > to insure a certain insensitivity in break of communication links, at least > for local provided services) ; so, in case of an ldap server failure, the > redundance must be assumed by the central servers group, with the help of > SRV resolutions that (will) allow the ... excellent openldap library ;) > It seems to me that SRV RRs definition is actually a quite good answer (easy > to deploy and, why not, standardized) to this problematic. IMHO DNS RRs are not a good failover mechanism. The LDAP clients would have to be quite smart to do the right thing. Especially if LDAP clients are writing to the directory servers. Ciao, Michael.

1 0

(ITS#5942) URI matching of "self" in add_syncrepl is incomplete
by jclarke＠linagora.com 12 Feb '09

12 Feb '09

Full_Name: Jonathan Clarke Version: RE24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.41.243.192) Hi, When adding a syncrepl config, the function add_syncrepl performs a "check if URL points to current server". This check is based on an exact match between the provider parameter from the syncrepl config line, and the URIs given to slapd on startup. If this doesn't match when it should, the database is marked as a shadow, and all following updates fail with "shadow context; no update refs". This is quite a pain when it happens on cn=config :) There are multiple cases when this happens: 1) If no specific URI was specified on launch (no -h option) 2) Port numbers are explicitly specified or not (":389") 3) Trailing slash (for example "ldap://1.2.3.4" != "ldap://1.2.3.4/") 4) IP is specified rather than DNS name ("ldap://localhost" != "ldap://127.0.0.1") I saw the comment in the code that clarifies this behaviour. However, it's a surprising behaviour, and I think there is code to parse this kind of thing in the serverID detection now. Maybe it could be reused? Otherwise, we should probably document this behaviour, to avoid headaches :)

1 0

(ITS#5941) Problem when stacking rwm and translucent overlays together
by bryan.mesich＠ndsu.edu 12 Feb '09

12 Feb '09

Full_Name: Bryan Mesich Version: 2.4.13 OS: RHEL 5.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:4930:106:0:212:3fff:fefb:2891) When a rwm overlay is used in conjunction with the translucent overlay, slapd dies with the following error and backtrace: *** glibc detected *** ./libexec/slapd: double free or corruption (fasttop): 0x0860ca38 *** ======= Backtrace: ========= /lib/libc.so.6[0x5ceac1] /lib/libc.so.6(cfree+0x90)[0x5d20f0] ./libexec/slapd(do_search+0x10e)[0x807bbfe] ./libexec/slapd[0x8079845] ./libexec/slapd[0x8079c12] ./libexec/slapd[0x816d504] /lib/libpthread.so.0[0x6f750b] /lib/libc.so.6(clone+0x5e)[0x638b2e] I have been able to reproduce this error in 2.4.11, 2.4.13 and the CVS HEAD as of Mon Feb 9 11:13:04 CST 2009. Here is portion of my configuration file: ############################################### # database backend modules to load moduleload back_ldap.la # overlay modules to load moduleload translucent.la moduleload rwm.la # local database database bdb suffix "dc=nodak,dc=edu" rootdn "cn=root,dc=nodak,dc=edu" rootpw secret directory /var/lib/ldap2.4 overlay translucent uri "ldap://ldap.nodak.edu/"; overlay rwm #rwm-rewriteEngine on #rwm-rewriteContext searchFilter #rwm-rewriteRule "^(.*objectClass=)posixAccount(.*)" "$1inetOrgPerson$2" ":@" #rwm-map attribute uidNumber NID ############################################### Simply declaring the rwm overlay (as shown in my configuration) is enough to produce the error when used with a translucent overlay. Slapd will usually answer one request after being started before tipping over. I'm open to testing if needed. Thanks in advance, Bryan

1 0

RE: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by philippe.eychart＠informatique.gov.pf 11 Feb '09

11 Feb '09

philippe.eychart(a)informatique.gov.pf wrote: > Used of SRV rr is a good reponse, (in particular in case of large Intranet > with many > remote sites -islands in pacific- and poor communication ressources - > satellite) but require > to be performed in all client applications : nssldap, samba, ldap client > tools > for rsync/mail/DNS/proxy/supervision definitions, ... or openldap. We are in this case : I work in Tahiti, for the french polynesian gouvernment, IT departement. Our intranet take in a big geographic area recovering several islands. I'm in charge to transfer of the totality of our management systems (and network config) in a centralized base (of course: openldap). But, in one hand, distant servers (and users) can't be submit to communication links quality, in particular concerning local services (authentifications, local messaging, samba service, etc ...) and in other hand, we can't multipy the number of ldap servers assuming redundence (quite services merged, we already manage more than 100 servers - and about 4000 pc). So, one local server in every remote site must assume ldap service for the other local servers (which assume different services for different administrative departements) to guarantee acceptable performances (and also to insure a certain insensitivity in break of communication links, at least for local provided services) ; so, in case of an ldap server failure, the redundance must be assumed by the central servers group, with the help of SRV resolutions that (will) allow the ... excellent openldap library ;) It seems to me that SRV RRs definition is actually a quite good answer (easy to deploy and, why not, standardized) to this problematic. -----Message d'origine----- De : Michael Ströder [mailto:michael@stroeder.com] Envoyé : mercredi 11 février 2009 06:44 À : philippe.eychart(a)informatique.gov.pf Cc : openldap-its(a)openldap.org Objet : Re: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine) philippe.eychart(a)informatique.gov.pf wrote: > Michael Ströder wrote: >> Frankly I'd vote against stuffing this into standard function >> ldap_initialize(). Using this without further pre-caution (like >> user-interaction) is broken in a similar way like chasing LDAPv3 >> referrals at the client side. > > I also think myself that security aspects are important ; but in other hand, > IMHO : it is of the responsibility of the DNS administrator to configure > cleanly and to protect its systems of any corruption (and maybe also to the > project BIND to improve tools allowing it). DNSSEC would be a solution. But my question is which problem to solve at first with SRV RRs? Ciao, Michael.

1 0

Re: (ITS#5940) crash in slapo-rwm when modifying olcRwmRewrite
by ando＠sys-net.it 11 Feb '09

11 Feb '09

At a very quick glance of your backtrace, info == 0; you didn´t olcRwmRewiteEngine TRUE? If it´s the case, the code needs to be reworked in this area. I can´t look at this now, in the meanwhile try to set it to TRUE as your first slapo-rmw statement. p. ----- jclarke(a)linagora.com wrote: > Full_Name: Jonathan Clarke > Version: RE24 > OS: CentOS > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (213.41.243.192) > > > Hi, > > Given a simple setup involving back-ldap with slapo-rwm on top, modifying the > attribute "olcRwmRewrite" causes a crash. This seems to happen both while > modifying an existing value, or when deleting one. > > The config: > 8<---------------------------- > # {1}ldap, config > dn: olcDatabase={1}ldap,cn=config > objectClass: olcDatabaseConfig > objectClass: olcLDAPConfig > olcDatabase: {1}ldap > olcSuffix: o=proxy > olcAddContentAcl: FALSE > olcLastMod: FALSE > olcMaxDerefDepth: 15 > olcReadOnly: FALSE > olcMonitoring: FALSE > olcDbURI: "ldap://server.lan" > olcDbStartTLS: none > olcDbIDAssertBind: mode=none flags=prescriptive bindmethod=simple timeout=0 ne > twork-timeout=0 binddn="cn=administrateur,cn=users,dc=otherdemo,dc=lan" creden > tials="secret" > olcDbRebindAsUser: FALSE > olcDbChaseReferrals: TRUE > olcDbTFSupport: no > olcDbProxyWhoAmI: FALSE > olcDbSingleConn: FALSE > olcDbCancel: abandon > olcDbUseTemporaryConn: FALSE > olcDbConnectionPoolMax: 16 > olcDbNoRefs: FALSE > olcDbNoUndefFilter: FALSE > > # {0}rwm, {1}ldap, config > dn: olcOverlay={0}rwm,olcDatabase={1}ldap,cn=config > objectClass: olcOverlayConfig > objectClass: olcRwmConfig > olcOverlay: {0}rwm > olcRwmRewrite: {0}rwm-suffixmassage "o=proxy" "dc=otherdemo,dc=lan" > olcRwmTFSupport: false > olcRwmNormalizeMapped: FALSE > 8<---------------------------- > > The operation: > 8<---------------------------- > dn: olcOverlay={0}rwm,olcDatabase={1}ldap,cn=config > changeType: modify > replace: olcRwmRewrite > olcRwmRewrite: {0}rwm-suffixmassage "o=proxy" "dc=demo,dc=lan" > > 8<---------------------------- > > > GDB output: > 8<---------------------------- > conn=4 fd=12 ACCEPT from IP=127.0.0.1:45843 (IP=0.0.0.0:389) > conn=4 op=0 BIND dn="cn=config" method=128 > conn=4 op=0 BIND dn="cn=config" mech=SIMPLE ssf=0 > conn=4 op=0 RESULT tag=97 err=0 text= > conn=4 op=1 MOD dn="olcOverlay={0}rwm,olcDatabase={1}ldap,cn=config" > conn=4 op=1 MOD attr=olcRwmRewrite > slapd: config.c:59: rewrite_parse: Assertion `info != ((void *)0)' failed. > > Program received signal SIGABRT, Aborted. > [Switching to Thread 1106893120 (LWP 31852)] > 0x0000003411a30155 in raise () from /lib64/libc.so.6 > (gdb) bt > #0 0x0000003411a30155 in raise () from /lib64/libc.so.6 > #1 0x0000003411a31bf0 in abort () from /lib64/libc.so.6 > #2 0x0000003411a295d6 in __assert_fail () from /lib64/libc.so.6 > #3 0x00000000004ea899 in rewrite_parse (info=0x0, fname=0x555ec5 "<suffix > massage>", lineno=1, argc=2, argv=0x41f9a180) at config.c:59 > #4 0x00000000004df8fe in rwm_suffix_massage_config (info=0x7c6a, > pvnc=0x41f9a220, nvnc=<value optimized out>, prnc=0x41f9a1f0, nrnc=<value > optimized out>) > at rwmconf.c:326 > #5 0x00000000004dc1bd in rwm_suffixmassage_config (be=<value optimized out>, > fname=0x523789 "slapd", lineno=0, argc=<value optimized out>, > argv=<value optimized out>) at rwm.c:1662 > #6 0x00000000004dc632 in rwm_cf_gen (c=0x41f9a620) at rwm.c:2076 > #7 0x0000000000414b7b in config_set_vals (Conf=0x7abc00, c=0x7c6c) at > config.c:314 > #8 0x000000000041835d in config_parse_add (ct=0x7abc00, c=0x41f9a620, > valx=<value optimized out>) at config.c:642 > #9 0x000000000040e63f in config_modify_add (ct=0x7abc00, ca=0x41f9a620, > ad=<value optimized out>, i=0) at bconfig.c:4806 > #10 0x0000000000410b03 in config_back_modify (op=0x1c8bf360, rs=0x41f9cc20) at > bconfig.c:5039 > #11 0x0000000000434317 in fe_op_modify (op=0x1c8bf360, rs=0x41f9cc20) at > modify.c:301 > #12 0x0000000000434a72 in do_modify (op=0x1c8bf360, rs=0x41f9cc20) at > modify.c:175 > #13 0x000000000041dd2b in connection_operation (ctx=0x41f9cd70, arg_v=<value > optimized out>) at connection.c:1097 > #14 0x000000000041e207 in connection_read_thread (ctx=0x41f9cd70, argv=<value > optimized out>) at connection.c:1223 > #15 0x00000000004f906a in ldap_int_thread_pool_wrapper (xpool=0x1c83c2d0) at > tpool.c:663 > #16 0x00002b6a8d3532f7 in start_thread () from /lib64/libpthread.so.0 > #17 0x0000003411ad1e3d in clone () from /lib64/libc.so.6 > 8<---------------------------- > > Let me know if you need any more details, or output from GDB. > > Regards, > Jonathan > > Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5940) crash in slapo-rwm when modifying olcRwmRewrite
by jclarke＠linagora.com 11 Feb '09

11 Feb '09

Full_Name: Jonathan Clarke Version: RE24 OS: CentOS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.41.243.192) Hi, Given a simple setup involving back-ldap with slapo-rwm on top, modifying the attribute "olcRwmRewrite" causes a crash. This seems to happen both while modifying an existing value, or when deleting one. The config: 8<---------------------------- # {1}ldap, config dn: olcDatabase={1}ldap,cn=config objectClass: olcDatabaseConfig objectClass: olcLDAPConfig olcDatabase: {1}ldap olcSuffix: o=proxy olcAddContentAcl: FALSE olcLastMod: FALSE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcMonitoring: FALSE olcDbURI: "ldap://server.lan" olcDbStartTLS: none olcDbIDAssertBind: mode=none flags=prescriptive bindmethod=simple timeout=0 ne twork-timeout=0 binddn="cn=administrateur,cn=users,dc=otherdemo,dc=lan" creden tials="secret" olcDbRebindAsUser: FALSE olcDbChaseReferrals: TRUE olcDbTFSupport: no olcDbProxyWhoAmI: FALSE olcDbSingleConn: FALSE olcDbCancel: abandon olcDbUseTemporaryConn: FALSE olcDbConnectionPoolMax: 16 olcDbNoRefs: FALSE olcDbNoUndefFilter: FALSE # {0}rwm, {1}ldap, config dn: olcOverlay={0}rwm,olcDatabase={1}ldap,cn=config objectClass: olcOverlayConfig objectClass: olcRwmConfig olcOverlay: {0}rwm olcRwmRewrite: {0}rwm-suffixmassage "o=proxy" "dc=otherdemo,dc=lan" olcRwmTFSupport: false olcRwmNormalizeMapped: FALSE 8<---------------------------- The operation: 8<---------------------------- dn: olcOverlay={0}rwm,olcDatabase={1}ldap,cn=config changeType: modify replace: olcRwmRewrite olcRwmRewrite: {0}rwm-suffixmassage "o=proxy" "dc=demo,dc=lan" 8<---------------------------- GDB output: 8<---------------------------- conn=4 fd=12 ACCEPT from IP=127.0.0.1:45843 (IP=0.0.0.0:389) conn=4 op=0 BIND dn="cn=config" method=128 conn=4 op=0 BIND dn="cn=config" mech=SIMPLE ssf=0 conn=4 op=0 RESULT tag=97 err=0 text= conn=4 op=1 MOD dn="olcOverlay={0}rwm,olcDatabase={1}ldap,cn=config" conn=4 op=1 MOD attr=olcRwmRewrite slapd: config.c:59: rewrite_parse: Assertion `info != ((void *)0)' failed. Program received signal SIGABRT, Aborted. [Switching to Thread 1106893120 (LWP 31852)] 0x0000003411a30155 in raise () from /lib64/libc.so.6 (gdb) bt #0 0x0000003411a30155 in raise () from /lib64/libc.so.6 #1 0x0000003411a31bf0 in abort () from /lib64/libc.so.6 #2 0x0000003411a295d6 in __assert_fail () from /lib64/libc.so.6 #3 0x00000000004ea899 in rewrite_parse (info=0x0, fname=0x555ec5 "<suffix massage>", lineno=1, argc=2, argv=0x41f9a180) at config.c:59 #4 0x00000000004df8fe in rwm_suffix_massage_config (info=0x7c6a, pvnc=0x41f9a220, nvnc=<value optimized out>, prnc=0x41f9a1f0, nrnc=<value optimized out>) at rwmconf.c:326 #5 0x00000000004dc1bd in rwm_suffixmassage_config (be=<value optimized out>, fname=0x523789 "slapd", lineno=0, argc=<value optimized out>, argv=<value optimized out>) at rwm.c:1662 #6 0x00000000004dc632 in rwm_cf_gen (c=0x41f9a620) at rwm.c:2076 #7 0x0000000000414b7b in config_set_vals (Conf=0x7abc00, c=0x7c6c) at config.c:314 #8 0x000000000041835d in config_parse_add (ct=0x7abc00, c=0x41f9a620, valx=<value optimized out>) at config.c:642 #9 0x000000000040e63f in config_modify_add (ct=0x7abc00, ca=0x41f9a620, ad=<value optimized out>, i=0) at bconfig.c:4806 #10 0x0000000000410b03 in config_back_modify (op=0x1c8bf360, rs=0x41f9cc20) at bconfig.c:5039 #11 0x0000000000434317 in fe_op_modify (op=0x1c8bf360, rs=0x41f9cc20) at modify.c:301 #12 0x0000000000434a72 in do_modify (op=0x1c8bf360, rs=0x41f9cc20) at modify.c:175 #13 0x000000000041dd2b in connection_operation (ctx=0x41f9cd70, arg_v=<value optimized out>) at connection.c:1097 #14 0x000000000041e207 in connection_read_thread (ctx=0x41f9cd70, argv=<value optimized out>) at connection.c:1223 #15 0x00000000004f906a in ldap_int_thread_pool_wrapper (xpool=0x1c83c2d0) at tpool.c:663 #16 0x00002b6a8d3532f7 in start_thread () from /lib64/libpthread.so.0 #17 0x0000003411ad1e3d in clone () from /lib64/libc.so.6 8<---------------------------- Let me know if you need any more details, or output from GDB. Regards, Jonathan

1 0

Re: (ITS#5756) 2.4 slapo-pcache only caches first lookup for certain templates
by toby＠inf.ed.ac.uk 11 Feb '09

11 Feb '09

Brilliant, many thanks for this. A simple test seems to confirm that it fixes the problem. I'll test in more detail and with more complex filters to confirm. Cheers Toby -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

Re: (ITS#5938) tls.c does not conform to RFC 4513
by hyc＠symas.com 10 Feb '09

10 Feb '09

nick.hudson(a)isode.com wrote: > Full_Name: nick hudson > Version: 2.3.38 > OS: linux > URL: > Submission from: (NULL) (62.3.217.250) > > > I am looking at the code in tls.c, function ldap_pvt_tls_check_hostname > (although the code has been refactored in recent versions, into e.g. tls_o.c, > but the same is true of the new code) > > I think the code is doing something that RFC 4513 says that it should not do. > Specifically, ref RFC 4513 section 3.1.3 says: > > The server's identity may also be verified by comparing the reference > identity to the Common Name (CN) [RFC4519] value in the leaf Relative > Distinguished Name (RDN) of the subjectName field of the server's > certificate. This comparison is performed using the rules for > comparison of DNS names in Section 3.1.3.1, below, with the exception > that no wildcard matching is allowed. > > In tls.c (and the refactored code), you can see it's first attempting an exact > comparison on subjectAltName, and if that fails it tries a wildcard match (which > is ok, as per section 3.1.3.1) > > But if no subjectAltName match is found, there's another section which looks at > the certificate's subjectname, in which it also does a wildcard match, although > the RFC says this shouldn't be done. I recall having a long argument against adding this, but we went with it in the end. The original patch was in ITS#3134. Some of the discussion surfaced here http://www.openldap.org/lists/openldap-software/200404/msg00434.html It carried on here http://www.openldap.org/lists/openldap-devel/200405/msg00002.html I'll also note ITS#5789, we allow matching an IP address against the CN too, and according to the spec that's only allowed for subjectAltName. But obviously there are lots of people out there misusing X.509, and we're tired of telling them to go do it right. It's a losing battle, we just get blamed for being broken... -- -- 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#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by philippe.eychart＠informatique.gov.pf 10 Feb '09

10 Feb '09

Pierangelo Masarati [mailto:ando@sys-net.it] wrote: > OpenLDAP clients do the following: > empty hostport, empty DN: localhost, default port > empty hostport, non-empty DN: SRV > what might be missing IMHO is: > use domain to specify SRV > however, I don't see any special need for it, as domain can always be > put in DN form. > I don't know if there's need for a form that asks to use SRV to discover > the server for the default SUFFIX. > In order to avoid issues, I recommend using something like > x-dnssrv={<domain>|<DN>} > where <DN> is restricted to the domain component sequence form. Ok, I start on this agreement ... So, is it a Good Thing (IYHO ;) to introduce this patch according the "followup 9" ?... One other possible solution could be (for example) to patch the ldap_connect_to_host() function in os-ip.c (around getaddrinfo() and ldap_pvt_gethostbyname_a() calls). However, samba (as an example) seems not to use it ... I think that the first solution remains the one who will have a minimal impact on the existing sources ... Michael Str.der wrote: > Frankly I'd vote against stuffing this into standard function > ldap_initialize(). Using this without further pre-caution (like > user-interaction) is broken in a similar way like chasing LDAPv3 > referrals at the client side. I also think myself that security aspects are important ; but in other hand, IMHO : it is of the responsibility of the DNS administrator to configure cleanly and to protect its systems of any corruption (and maybe also to the project BIND to improve tools allowing it). Although it is there, the advantage of the suggested solution ("followup 9") is as well as this patch can be located as well within the function ldap_initialize() as within another frontal function (according to what will be finally decided ;). --- PE

1 0

Re: (ITS#5931) back-meta crashes with syncrepl data
by ando＠sys-net.it 10 Feb '09

10 Feb '09

> Right, I did the same first with test017. I've now repeated with > test018, > which works fine since the intermediate message carries the sync > cookie. Ah, I never checked refreshOnly, as it's not an option I use often. Well, the issue about response controls needs to be solved at some point. In any case, proxying syncrepl this way should not be regular usage. I'm happy it helped sorting out some issues in the proxies. Fine for the liblber patch to be backed out, then. I can't test right now, but I don't see any reason to have a different behavior than yours. What puzzles me now is that I had to rework entry parsing in back-meta to prevent it eating entry controls while parsing attributes, but back-ldap didn't need anything like that... p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5931) back-meta crashes with syncrepl data
by hyc＠symas.com 10 Feb '09

10 Feb '09

Pierangelo Masarati wrote: > ----- hyc(a)symas.com ha scritto: > >> hyc(a)symas.com wrote: >>> I'll play with this code some with the decode change backed out. >>> >> Heh, in my current build I hadn't updated liblber yet so I didn't have >> the >> change. Fwiw, test036 etc. worked fine without it. Will try some >> syncrepl >> configs now. > > I ran test018, then I put a back-meta between the consumer and the > producer, I wiped the consumer's database and restarted it. Then I performed some further modifications to the producer and checked that they appeared in the consumer. Right, I did the same first with test017. I've now repeated with test018, which works fine since the intermediate message carries the sync cookie. > Please pay attention to the proxy's logs: what you could (should) get is a series of messages complaining about the impossibility to decode attribute types. I didn't see any such errors in the proxy's logs, and the consumer was fine. > I might well have screwed something up while trying to fix intermediate responses and other stuff related to this ITS. That's why I'm asking for critical review before merging my fix into re24. With the change in liblber I could perform syncrepl with back-meta in between. refreshAndPersist seems to work fine without the liblber 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#5931) back-meta crashes with syncrepl data
by hyc＠symas.com 10 Feb '09

10 Feb '09

hyc(a)symas.com wrote: > hyc(a)symas.com wrote: >> I'll play with this code some with the decode change backed out. >> > Heh, in my current build I hadn't updated liblber yet so I didn't have the > change. Fwiw, test036 etc. worked fine without it. Will try some syncrepl > configs now. > back-meta passes search entry controls fine without the liblber patch. But since back-meta doesn't pass result controls, (ITS#4591) it never propagates the final cookie in refreshonly mode, so the consumer always gets a full refresh every time it reconnects. I'm going to revert the liblber 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#5931) back-meta crashes with syncrepl data
by ando＠sys-net.it 10 Feb '09

10 Feb '09

----- hyc(a)symas.com ha scritto: > hyc(a)symas.com wrote: > > I'll play with this code some with the decode change backed out. > > > Heh, in my current build I hadn't updated liblber yet so I didn't have > the > change. Fwiw, test036 etc. worked fine without it. Will try some > syncrepl > configs now. I ran test018, then I put a back-meta between the consumer and the producer, I wiped the consumer's database and restarted it. Then I performed some further modifications to the producer and checked that they appeared in the consumer. Please pay attention to the proxy's logs: what you could (should) get is a series of messages complaining about the impossibility to decode attribute types. I might well have screwed something up while trying to fix intermediate responses and other stuff related to this ITS. That's why I'm asking for critical review before merging my fix into re24. With the change in liblber I could perform syncrepl with back-meta in between. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5931) back-meta crashes with syncrepl data
by hyc＠symas.com 10 Feb '09

10 Feb '09

hyc(a)symas.com wrote: > I'll play with this code some with the decode change backed out. > Heh, in my current build I hadn't updated liblber yet so I didn't have the change. Fwiw, test036 etc. worked fine without it. Will try some syncrepl configs now. -- -- 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#5931) back-meta crashes with syncrepl data
by hyc＠symas.com 10 Feb '09

10 Feb '09

Pierangelo Masarati wrote: > ----- "Howard Chu"<hyc(a)symas.com> ha scritto: > >> ando(a)sys-net.it wrote: >>> I'm trying to modify the code in order to compute the size of the >>> SearchResultEntry portion of the message, but again, in some cases, >> the >>> size is computed incorrectly: the computed length is 4 octets >> shorter >>> than what's actually in the packet. >>> >>> One issue seems to be related to the fact that when ber_skip_tag() >>> checks if the length it's computed fits in the ber by calling >>> ber_pvt_ber_remaining(), it doesn't count that earlier calls to >>> ber_read() moved the ber_ptr forward. The original ber_ptr should >> be saved. >> >> This sounds wrong; the bytes that ber_read() advanced comprise the >> length >> bytes, but they're not included in the total that the length is >> counting. >> Therefore they should not be accounted for here. > > But without this fix ber_scanf("l") LBER_ERROR was failing because > ber_pvt_ber_remaining(), which is actually ber_end - ber_ptr, is shorter > than *len by the bytes that the ber_reads are advancing. Feel free to back > this out, if you're sure it's incorrect. I'll recheck the syncrepl over > back-meta. Pretty sure. Notice ber_first_element: *last = ber->ber_ptr + *len; All of this has been working for quite a long time... I'll play with this code some with the decode change backed out. -- -- 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#5931) back-meta crashes with syncrepl data
by ando＠sys-net.it 10 Feb '09

10 Feb '09

----- "Howard Chu" <hyc(a)symas.com> ha scritto: > ando(a)sys-net.it wrote: > > I'm trying to modify the code in order to compute the size of the > > SearchResultEntry portion of the message, but again, in some cases, > the > > size is computed incorrectly: the computed length is 4 octets > shorter > > than what's actually in the packet. > > > > One issue seems to be related to the fact that when ber_skip_tag() > > checks if the length it's computed fits in the ber by calling > > ber_pvt_ber_remaining(), it doesn't count that earlier calls to > > ber_read() moved the ber_ptr forward. The original ber_ptr should > be saved. > > This sounds wrong; the bytes that ber_read() advanced comprise the > length > bytes, but they're not included in the total that the length is > counting. > Therefore they should not be accounted for here. But without this fix ber_scanf("l") LBER_ERROR was failing because ber_pvt_ber_remaining(), which is actually ber_end - ber_ptr, is shorter than *len by the bytes that the ber_reads are advancing. Feel free to back this out, if you're sure it's incorrect. I'll recheck the syncrepl over back-meta. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5931) back-meta crashes with syncrepl data
by hyc＠symas.com 10 Feb '09

10 Feb '09

ando(a)sys-net.it wrote: > I'm trying to modify the code in order to compute the size of the > SearchResultEntry portion of the message, but again, in some cases, the > size is computed incorrectly: the computed length is 4 octets shorter > than what's actually in the packet. > > One issue seems to be related to the fact that when ber_skip_tag() > checks if the length it's computed fits in the ber by calling > ber_pvt_ber_remaining(), it doesn't count that earlier calls to > ber_read() moved the ber_ptr forward. The original ber_ptr should be saved. This sounds wrong; the bytes that ber_read() advanced comprise the length bytes, but they're not included in the total that the length is counting. Therefore they should not be accounted for here. > I don't believe messages are encoded incorrectly, so I must be doing > something wrong in decoding them... -- -- 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#5939) Missing close of file descriptor
by hyc＠symas.com 10 Feb '09

10 Feb '09

joakim.bentholm(a)birdstep.com wrote: > Full_Name: Joakim Bentholm > Version: OpenLDAP 2.4.13 > OS: FreeBSD 7.0 Release > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (217.13.255.38) > > > The running setup: > An ldap server with a socket back-end communicating with server process > listening on incoming requests from the socket back-end and replying in an > orderly fashing. > > The failure: > If the server process shuts down, the socket back-end will continue to try to > connect and allocating new file descriptors which will never be released. If the > server process is restarted everything will work, unless the file descriptor > limit have been reached, in case the ldap server have to be restart. Thanks for the report and patch, fixed now in HEAD. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5938) tls.c does not conform to RFC 4513
by quanah＠zimbra.com 10 Feb '09

10 Feb '09

--On February 10, 2009 5:28:24 PM +0100 Hallvard B Furuseth <h.b.furuseth(a)usit.uio.no> wrote: > quanah(a)zimbra.com writes: >> This is because the Cert vendors themselves don't honor the RFC's when >> issuing wildcard certs, and was added so that their broken wildcard >> certs could still be used. > > In that case, maybe there should be a config option to turn this > behavior on/off, and documentation which explains that it breaks TLS > the standard and why it does so. > > If nothing else, it may get more people to complain to the cert vendors. I spent something like 4 hours on the phone discussing the issue with one of the cert vendors. They still didn't understand what was wrong with their cert, and to this day they still issue the same style of certs. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5938) tls.c does not conform to RFC 4513
by Kurt＠OpenLDAP.org 10 Feb '09

10 Feb '09

On Feb 10, 2009, at 8:29 AM, h.b.furuseth(a)usit.uio.no wrote: > quanah(a)zimbra.com writes: >> This is because the Cert vendors themselves don't honor the RFC's >> when >> issuing wildcard certs, and was added so that their broken wildcard >> certs could still be used. > > In that case, maybe there should be a config option to turn this > behavior on/off, and documentation which explains that it breaks TLS > the standard and why it does so. I think it reasonable to be liberal in what we accept in this particular case. It's not like someone is actually going to name a host '*'. If they do, their certificate matching more hosts than they expect will be just one of many problems they face. > > > If nothing else, it may get more people to complain to the cert > vendors. Far more persons would complain to the OpenLDAP Project.

1 0

Re: (ITS#5938) tls.c does not conform to RFC 4513
by h.b.furuseth＠usit.uio.no 10 Feb '09

10 Feb '09

quanah(a)zimbra.com writes: > This is because the Cert vendors themselves don't honor the RFC's when > issuing wildcard certs, and was added so that their broken wildcard > certs could still be used. In that case, maybe there should be a config option to turn this behavior on/off, and documentation which explains that it breaks TLS the standard and why it does so. If nothing else, it may get more people to complain to the cert vendors. -- Hallvard

1 0

Re: (ITS#5938) tls.c does not conform to RFC 4513
by Kurt＠OpenLDAP.org 10 Feb '09

10 Feb '09

On Feb 10, 2009, at 7:56 AM, nick.hudson(a)isode.com wrote: > Full_Name: nick hudson > Version: 2.3.38 > OS: linux > URL: > Submission from: (NULL) (62.3.217.250) > > > I am looking at the code in tls.c, function > ldap_pvt_tls_check_hostname > (although the code has been refactored in recent versions, into e.g. > tls_o.c, > but the same is true of the new code) > > I think the code is doing something that RFC 4513 says that it > should not do. > Specifically, ref RFC 4513 section 3.1.3 says: > > The server's identity may also be verified by comparing the > reference > identity to the Common Name (CN) [RFC4519] value in the leaf > Relative > Distinguished Name (RDN) of the subjectName field of the server's > certificate. This comparison is performed using the rules for > comparison of DNS names in Section 3.1.3.1, below, with the > exception > that no wildcard matching is allowed. > > In tls.c (and the refactored code), you can see it's first > attempting an exact > comparison on subjectAltName, and if that fails it tries a wildcard > match (which > is ok, as per section 3.1.3.1) > > But if no subjectAltName match is found, there's another section > which looks at > the certificate's subjectname, in which it also does a wildcard > match, although > the RFC says this shouldn't be done. This is a case where OpenLDAP library is purposely being 'liberal in what it accepts'. -- Kurt

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs