openldap-bugs

openldap-bugs@openldap.org

1 participants
20969 discussions

Re: (ITS#7271) Don't clobber SASL_NOCANON in clients/tools/common.c
by hyc＠symas.com 30 May '12

30 May '12

W. Trevor King wrote: > On Wed, May 30, 2012 at 06:14:38AM -0700, Howard Chu wrote: >> Ideally the command line option should have been able to set this >> explicitly to both true and false, to allow complete control over >> the option. But I'm not particularly concerned either way. Since the >> option currently can only be set to true, it would be sufficient to >> just check for nocanon != 0 before calling ldap_set_option. > > My personal goal here is to not need to bother with command line > options, so I'm fine with this less general solution. Another patch > (only set the option with an explicit `-N`) attached. > > --- > The attached patch file is derived from OpenLDAP Software. All of the > modifications to OpenLDAP Software represented in the following > patch(es) were developed by W. Trevor King wking(a)tremily.us. I have > not assigned rights and/or interest in this work to any party. > > I, W. Trevor King, 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. > Thanks, added to master. -- -- 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#7271) Don't clobber SASL_NOCANON in clients/tools/common.c
by wking＠tremily.us 30 May '12

30 May '12

--oLBj+sq0vYjzfsbl Content-Type: multipart/mixed; boundary="yrj/dFKFPuw6o+aM" Content-Disposition: inline --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 30, 2012 at 06:14:38AM -0700, Howard Chu wrote: > Ideally the command line option should have been able to set this > explicitly to both true and false, to allow complete control over > the option. But I'm not particularly concerned either way. Since the > option currently can only be set to true, it would be sufficient to > just check for nocanon !=3D 0 before calling ldap_set_option. My personal goal here is to not need to bother with command line options, so I'm fine with this less general solution. Another patch (only set the option with an explicit `-N`) attached. --- The attached patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by W. Trevor King wking(a)tremily.us. I have not assigned rights and/or interest in this work to any party. I, W. Trevor King, 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. --=20 This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="tool-nocanon.patch" Content-Transfer-Encoding: quoted-printable diff --git a/clients/tools/common.c b/clients/tools/common.c index 9c98b62..e928fb2 100644 --- a/clients/tools/common.c +++ b/clients/tools/common.c @@ -1410,12 +1410,13 @@ dnssrv_free:; =20 #ifdef HAVE_CYRUS_SASL /* canon */ - if( ldap_set_option( ld, LDAP_OPT_X_SASL_NOCANON, - nocanon ? LDAP_OPT_ON : LDAP_OPT_OFF ) !=3D LDAP_OPT_SUCCESS ) - { - fprintf( stderr, "Could not set LDAP_OPT_X_SASL_NOCANON %s\n", - nocanon ? "on" : "off" ); - tool_exit( ld, EXIT_FAILURE ); + if( nocanon ) { + if( ldap_set_option( ld, LDAP_OPT_X_SASL_NOCANON, + LDAP_OPT_ON ) !=3D LDAP_OPT_SUCCESS ) + { + fprintf( stderr, "Could not set LDAP_OPT_X_SASL_NOCANON on\n" ); + tool_exit( ld, EXIT_FAILURE ); + } } #endif if( ldap_set_option( ld, LDAP_OPT_PROTOCOL_VERSION, &protocol ) --yrj/dFKFPuw6o+aM-- --oLBj+sq0vYjzfsbl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iQIcBAEBAgAGBQJPxjviAAoJEEUbTsx0l5OM4+AQALnDBr4YL5g8BIgsU7Fvea1O 3cCh+arj8S3mFsltqKnvOZTRqnPp9yafmCKzLnb8DP3xstXFwF3A/J1o8+Ptzi9d v5EbYd/+jUp1kQBAQHclS87OwjijgHuZtRZxcJXbh4CrV7T/FG6byiVvpFpxR06O ug306vFhqhBk1FpbUJU+R0u7gzUaTjhW4O/RE9kPEaqnkSSfd+NuCF1L8ZHzmAOc xA8gJgUVP5GOgfrZeoQjuyO+mGOVpHPjcybs1VThyhbLWwPKb/RExdTa/0x+A/p8 hVlM9C9SGr1UC3QQaboSON0rhP4UjHc/HCA53Ijgw+vCr0KiaUDjaiG83ydj0EfY Q71IF/PY286lUCLorw1ZJqtAP1dRbpWCk+45A4ZoMR6zWgUUX1L27v7gD5pUQZWW J85OU8D1OFuH1tYNXp+6VgiQpO5ofwQTaQo2puVOjwGpgjCjl1g69kWLjle9JvEv cRZ9wuT3rfVc9Ujv/Tqirw6cy+1QJopKjRlHcV1RX6j34RFBfc9qwcM/3BC1sMGD 2IDRte87sUAq+i3bM43iFujTI9AwUd3pAP/9x2D7tnrr4t5ixV+MBtaNmWtblBos XHeReDSakxipIfBxJtQTSTeKrb7VPS4d7RpUEg5etXLIxVaJyVpSTl0G3b8tWwC0 yZySTz5NthLULma8573R =lyIG -----END PGP SIGNATURE----- --oLBj+sq0vYjzfsbl--

1 0

Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by Kurt＠OpenLDAP.org 30 May '12

30 May '12

On May 29, 2012, at 1:38 PM, michael(a)stroeder.com wrote: > Still you did not answer why SHA-1 is in and SHA-2 is out. Well, the general rule is simply all new hash schemes should go in contrib first. What you ask is for an exception to this general rule for SHA-2. I don't see the arguments for the exception being all that strong. Arguing it should be "in" because SHA-1 is "in" is a really poor argument. SHA-1 is "in" because it was grandfathered in. SHA-2, like any new hash scheme, is "out" because of the current practice to put new schemes in contrib. It's as simple as that, I think. I do note that there's many issues bring hashes into core. One key one is that core schemes ought to work with minimal 3rd party libraries, and that means without OpenSSL. So bringing these schemes also means, if we hold to this, bring in a SHA2 implementation into core... and that's gets, well, more involved. And that's one of reasons we have the core/contrib split. Anyways, I personally think no exception should be granted, these schemes should go into contrib like any other new hash scheme would. I've thought a bit about whether slappasswd should or should not load modules. I stand against slapppasswd reading slapd configuration by default. I would not object to reading slapd configuration when specifically requested by the user (by a command line argument). I generally run slappasswd (for setup purposes) as a user which has no access to slapd configuration. This not only for convenience, but for security reasons (limit programs which can read the configuration, as the configuration contains sensitive information). While if I needed some scheme only in contrib I might resort to other means to generate the hash (such as a little perl), I don't object to slappasswd, when requested by option, reading the configuration, loading the modules, and generating the hash. I would only object if slappasswd did this by default, as that would cause me to have to use other means even for core schemes. -- Kurt

1 0

Re: (ITS#7276) [PATCH] MozNSS: allow CA certdb together with PEM CA bundle file
by hyc＠symas.com 30 May '12

30 May '12

jvcelak(a)redhat.com wrote: > Full_Name: Jan Vcelak > Version: master > OS: Linux > URL: ftp://ftp.openldap.org/incoming/jvcelak-20120518-update-nss-allow-ca-certdb… > Submission from: (NULL) (209.132.186.34) > > > With Mozilla NSS crypto backend: > > Prior to this patch, if TLS_CACERTDIR was set to Mozilla NSS certificate > database and TLS_CACERT was set to a PEM bundle file with CA > certificates, the PEM file content was not loaded. > > With this patch and the same settings, OpenLDAP can verify certificates > which are signed by CAs stored both in certdb and PEM bundle file. Thanks for the patch, added to master. > > This problem was found with FreeIPA which is setting CA PEM bundle using > ldap_set_option(&ld, LDAP_OPT_X_TLS_CACERTFILE, ...), while TLS_CACERTDIR with > certdb is set in system ldap.conf file. > > > The attached file is derived from OpenLDAP Software. All of the modifications to > OpenLDAP Software represented in the following patch(es) were developed by Red > Hat. Red Hat has not assigned rights and/or interest in this work to any party. > I, Jan Vcelak am authorized by Red Hat, my employer, to release this work under > the following terms. > > Red Hat 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. > > -- -- 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#7271) Don't clobber SASL_NOCANON in clients/tools/common.c
by hyc＠symas.com 30 May '12

30 May '12

wking(a)tremily.us wrote: > Full_Name: W. Trevor King > Version: git commit 22bf5188 > OS: Gentoo > URL: http://blog.tremily.us/posts/LDAP/tool-nocanon.patch > Submission from: (NULL) (72.68.88.202) > > > The ldap.conf SASL_NOCANON configuration option (or LDAPSASL_NOCANON environment > variable) should set the default behaviour for OpenLDAP tools such as > ldapwhoami. This configuration option should allow users to use the tools > without having to use the matching command line option (-N). Unfortunately, the > current code sets the option to true/false after only querying the command line > option. > > I'm linking to a patch that looks at the current value of the option first, and > if it's true, skips processing the command line option (which would either be a > redundant -N keeping the option true, or an absence of -N which implies the user > wants to use the configured value (true)). > > Another approach would be to set the initial value of nocanon to UNINITIALIZED > (-1?). Command line arguments could set nocanon to 1 (true, -N) or false (0, > --canon?). Then we would only call ldap_set_option if nocanon was not > UNINITIALIZED. > > I can work up a patch using this second approach if people prefer. If so, let > me know if you want me to define UNINITIALIZED, or to just use -1. > > I didn't check, but I would not be surprised if this same clobbering occurred > for other command line options. The only other boolean command line option is referrals, which is deprecated and has been undocumented for years. Not worth bothering over. Ideally the command line option should have been able to set this explicitly to both true and false, to allow complete control over the option. But I'm not particularly concerned either way. Since the option currently can only be set to true, it would be sufficient to just check for nocanon != 0 before calling ldap_set_option. -- -- 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#7270) Double free in ldap_int_initialize
by hyc＠symas.com 30 May '12

30 May '12

fdeweerdt(a)cloudmark.com wrote: > Full_Name: Frederik Deweerdt > Version: current HEAD > OS: Linux > URL: ftp://ftp.openldap.org/incoming/Frederik-Deweerdt-120511.patch > Submission from: (NULL) (72.5.239.5) > > > [PATCH] Protect accesses to ldap_int_hostname with a mutex Thanks for the patch, now in git master. > > > Not protecting the accesses to ldap_int_hostname would lead to a double > free with the following trace: > > #7 0x0000003aca031d10 in abort () from /lib64/libc.so.6 > No symbol table info available. > #8 0x0000003aca06a99b in __libc_message () from /lib64/libc.so.6 > No symbol table info available. > #9 0x0000003aca0729d6 in free () from /lib64/libc.so.6 > No symbol table info available. > #10 0x000000328902333e in ldap_int_initialize () > from /usr/lib64/libldap-2.3.so.0 > No symbol table info available. > #11 0x000000328900c426 in ldap_create () from /usr/lib64/libldap-2.3.so.0 > No symbol table info available. > #12 0x000000328900ca0d in ldap_init () from /usr/lib64/libldap-2.3.so.0 > No symbol table info available. > > The race in init.c:ldap_int_initialize is as follows: > 646 char *name = ldap_int_hostname; > 647 > 648 ldap_int_hostname = ldap_pvt_get_fqdn( name ); > 649 > 650 if ( name != NULL && name != ldap_int_hostname ) { > 651 LDAP_FREE( name ); > 652 } > > - T1 and T2 enter ldap_int_initialize, both assign to name the current > address of ldap_int_hostname, say 0x1234. > - T1 and T2 call ldap_pvt_get_fqdn(), updating ldap_int_hostname to 0x1235 > and 0x1236 respectively. > - T1 and T2 reach the name != ldap_int_hostname check. In both threads > it's false, because 0x1235 != 0x1234 and 0x1236 != 0x1234, respectively. > - T1 and T2 both try to free 0x1234 => Crash. > --- > libraries/libldap/init.c | 2 ++ > libraries/libldap/ldap-int.h | 1 + > libraries/libldap/util-int.c | 3 +++ > 3 files changed, 6 insertions(+), 0 deletions(-) > > > -- -- 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#7283) Usage of private headers make building out-of-tree extensions painful
by hyc＠symas.com 30 May '12

30 May '12

guillomovitch(a)gmail.com wrote: > Full_Name: Guillaume Rousse > Version: any > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.93.30.10) > > > In order to build out of tree extensions, such as ppolicy external password > checker (http://ltb-project.org/wiki/documentation/openldap-ppolicy-check-password), > you need additional slapd headers, portable.h and slapd.h (and a bunch of > additional dependant ones), which are currently not installed, and thus > considered as private. > > A request to ship those headers was refused by fedora package maintainer, > precisely for this reason: > https://bugzilla.redhat.com/show_bug.cgi?id=812860 They gave the right answer. The slap.h header is private and subject to change without notice. > The situation ought to be clarified, and some kind of solution found, as > maintaining a custom slapd build just to be able to benefit from this > extensability is largely overkill. Probably this should be discussed on the openldap-devel mailing list. There's no straightforward solution to this request. In the case of the LTB password checker module, there's barely any need for slap.h; the module could easily be tweaked to avoid all references to it. -- -- 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#7279) Apparently mdb "approx" index generation failure for mdb_add for syncrepl consumer
by hyc＠symas.com 30 May '12

30 May '12

brandon.hume(a)dal.ca wrote: > Full_Name: Brandon Hume > Version: 2.4.31 > OS: RHEL EL6.1, kernel 2.6.32-131.12.1.el6.x86_64 > URL: http://den.bofh.ca/~hume/mdb_approx_indexfail.tar > Submission from: (NULL) (2001:410:a010:2:223:aeff:fe74:400e) > > > An empty syncrepl consumer using mdb backend will suffer index generator > failures when populating its database from the provider and using "approx" index > options. The failure manifests in syslog (with olcLogLevel=Stats) as the > following: > > May 24 11:50:41 node2 slapd[25282]: null_callback : error code 0x50 > May 24 11:50:41 node2 slapd[25282]: syncrepl_entry: rid=001 be_add $DN failed > (80) > > These problems don't seem to occur when populating the provider using slapadd. > The problem only seems to manifest when the new entry arrives via syncrepl. > Playing with gdb, it seems like indexer() ends up being called with { bv_len = > 0, bv_val = "" } when indexing "givenName". Thanks for the report, fixed now in git master. slapadd also failed for me, so it wasn't quite the same behavior you reported. > > Could be because "givenName" on the troublesome entry is only one character? > > A minimalist DIT and config are provided in the tarfile in the link. The two > nodes are running in mirrormode, and I'm not sure if that makes a difference. The config is invalid; you have used the same RIDs multiple times. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7283) Usage of private headers make building out-of-tree extensions painful
by guillomovitch＠gmail.com 30 May '12

30 May '12

Full_Name: Guillaume Rousse Version: any OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.93.30.10) In order to build out of tree extensions, such as ppolicy external password checker (http://ltb-project.org/wiki/documentation/openldap-ppolicy-check-password), you need additional slapd headers, portable.h and slapd.h (and a bunch of additional dependant ones), which are currently not installed, and thus considered as private. A request to ship those headers was refused by fedora package maintainer, precisely for this reason: https://bugzilla.redhat.com/show_bug.cgi?id=812860 The situation ought to be clarified, and some kind of solution found, as maintaining a custom slapd build just to be able to benefit from this extensability is largely overkill.

1 0

Re: (ITS#7274) delta-syncrepl MMR infinite loop
by quanah＠zimbra.com 29 May '12

29 May '12

--On Tuesday, May 29, 2012 6:25 PM -0700 Howard Chu <hyc(a)openldap.org> wrote: >> so it is tracking "000" as a third master? This seems to be why the >> original server (which was 000 before being promoted to 001) replicates >> these entries back to itself. > > The loop is caused by the patch to ITS#6872, which considers a consumer > out of date whenever the number of CSNs in its sync request doesn't match > the number known to the provider. > > The data here is basically invalid: server1 has entries generated using > SID=0 but it has no contextCSN value with SID=0. It only sent SID=1 and > SID=2 in its sync request. Server2, which just updated from server1, has > a contextCSN for SID=0 in addition to 1 and 2 (and that's all correct). > > Server1 should have always had a contextCSN value for SID=0 but doesn't. > This problem would not occur if server1 was converted first from > standalone into a single-master. I.e., load syncprov on it, let it scan > the DB and generate the first sid=0 contextCSN, before turning it intu a > MMR node. For documentation purposes -- The issue occurred because I set olcServerID before I loaded syncprov. Re-ordering my script to load syncprov (which then caused a contextCSN value to be correctly generated on Server1 for SID=0) fixed this loop. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs