openldap-bugs September 2017

openldap-bugs@openldap.org

35 participants
128 discussions

Re: (ITS#8508) PATCH - ucgendat.c properly add title-case characters without upper-case equivalents (e.g. greek letters with iota subscript)
by quanah＠symas.com 07 Sep '17

07 Sep '17

Hello Zebediah, Thanks for your submission. However your report is missing an IPR which is required for it to be included with OpenLDAP. Please see <http://www.openldap.org/devel/contributing.html> for futher information on how to provide the required IPR information. Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8349) fix ppolicy issue
by quanah＠symas.com 07 Sep '17

07 Sep '17

--On Tuesday, January 12, 2016 7:28 AM +0000 hamano(a)osstech.co.jp wrote: > Full_Name: HAMANO Tsukasa > Version: 2.4.43 > OS: Linux > URL: > https://www.osstech.co.jp/download/hamano/openldap/ppolicy_fix_pwdInHisto > ry.patch Submission from: (NULL) (240b:10:2640:bf0:290:4cff:fe0d:f43e) > > > We fixed several issue around ppolicy. > > 1) reduce pwdInHistory > If set pwdInHistory to 5 then reduce pwdInHistory to 3, > We expect to check password with three history, but ppolicy check > password with all pwdHistory attribute. > > 2) reduce pwdInHistory to zero > If set pwdInHistory to 5 then reduce pwdInHistory to 0, > We expect that ppolicy password checking will be disbale. but the > pwdHistory attribute are remains, so password checking is still > enabled. > We need to remove pwdHistory attribute. Hi, I'm working on catching up on old ITS submissions. This submission is missing an IPR and cannot be included until it is provided. Please see <http://www.openldap.org/devel/contributing.html> for information on the IPR requirements. Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8724) slapo-pcache truncates remote results
by adam＠brainfood.com 07 Sep '17

07 Sep '17

Cool. I've looked at pcache.c, and realized I'm a noob with this code. Basically, my thoughts, is that pcache should ignore the incoming search request, and recreate it's own with it's own options, always asking for paging. Then page through all the results from the backend, then store the full set in the backing store. While that is going on, the cache entry should be marked with a bit flag saying that it's in the process of being built, but otherwise can still store the entries fetched thus far. Meanwhile, the frontend request can begin to return results from this partially resolved backend entry stored in the cache, utilizing whatever pagination value(and or offset/limit) has been requested. Of course, that's just the high-level description, not even really pseudo-code ready. As an aside, and this s/b a separate bug, if an error occurs from the backend this does *not* get cached. Aka, during this investigation, my backend is returning 2000 entries, err=4. This takes 7s each time(I'm in Dallas, while the backend is in California, and I'm communicating over a tunnel). It's not cached, so the request is passed through each time. I've configured the templates correctly, and the debug shows that the request is CACHEABLE. On Wed, Sep 6, 2017 at 6:22 PM, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Wednesday, September 06, 2017 7:06 PM -0500 Adam Heath > <adam(a)brainfood.com> wrote: > > >> Well, then since you are confirming the bug, I would say this ticket >> should *not* be closed. > > > I already reopened it. ;) > >> I might just have to patch this to make it work. > > > Make sure you follow the contribution guidelines: > > <https://www.openldap.org/devel/contributing.html> > > Thanks, > > Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

1 0

Re: (ITS#7996) Global initialisation race in ldap_int_initialize
by quanah＠symas.com 07 Sep '17

07 Sep '17

--On Tuesday, December 09, 2014 6:14 PM +0000 a.cudbardb(a)freeradius.org wrote: > Full_Name: Arran Cudbard-Bell > Version: 2.4.40 > OS: OSX 10.10.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (69.196.165.104) Hi Arran, Thanks for the report and sorry for the delay on getting to this issue. I would note that for the fix to be included in the OpenLDAP project, we need an IPR statement, as noted at <https://www.openldap.org/devel/contributing.html>. If you can provide that, and (if possible) submit the patch as git format-patch via the project FTP server (include the URL in your email), then I can pull it in. Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8436) slapadd hang in bdb_tool_entry_close / ldap_pvt_thread_cond_wait
by quanah＠symas.com 07 Sep '17

07 Sep '17

Hi Mark, I would note that no patch for this issue has ever been submitted to the tracker, nor is there any IPR, etc. I did track down your suggested fix via the mailing list thread. However, that is not sufficient for it to be included in the OpenLDAP project. Please see <http://www.openldap.org/devel/contributing.html> for the correct procedure for submitting your fix if you would like it to be included. Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8674) Leak in ldap_create_assertion_control
by come＠opensides.be 07 Sep '17

07 Sep '17

--nextPart2367739.nNEjSNJblS Content-Type: multipart/mixed; boundary="nextPart4704199.6R7aSYJDEk" Content-Transfer-Encoding: quoted-printable This is a multi-part message in MIME format. --nextPart4704199.6R7aSYJDEk Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Hello, I encountered this bug as well while adding controls support into php-ldap (see https://github.com/php/php-src/pull/2640 - WIP) I used the work-around but it would still be better to fix this in openldap. Please consider merging the attached patch. --nextPart4704199.6R7aSYJDEk Content-Disposition: attachment; filename="0001-Fixing-8674-Leak-in-ldap_create_assertion_control.patch" Content-Transfer-Encoding: 7Bit Content-Type: text/x-patch; charset="UTF-8"; name="0001-Fixing-8674-Leak-in-ldap_create_assertion_control.patch" From=2059e15d7cd5217312fcc6e3343476416a39cdc739 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?C=C3=B4me=20Chilliet?= <come(a)opensides.be> Date: Thu, 7 Sep 2017 17:11:57 +0200 Subject: [PATCH] Fixing #8674 Leak in ldap_create_assertion_control ldap_create_assertion_control_value was returning ld->ld_errno upon success without reseting it to LDAP_SUCCESS first --- libraries/libldap/assertion.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libraries/libldap/assertion.c b/libraries/libldap/assertion.c index 8ccd5c188..e736d59eb 100644 --- a/libraries/libldap/assertion.c +++ b/libraries/libldap/assertion.c @@ -31,6 +31,8 @@ ldap_create_assertion_control_value( BerElement *ber = NULL; int err; + ld->ld_errno = LDAP_SUCCESS; + if ( assertion == NULL || assertion[ 0 ] == '\0' ) { ld->ld_errno = LDAP_PARAM_ERROR; return ld->ld_errno; -- 2.11.0 --nextPart4704199.6R7aSYJDEk-- This is a multi-part message in MIME format. --nextPart4704199.6R7aSYJDEk Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Hello, I encountered this bug as well while adding controls support into php-ldap (see https://github.com/php/php-src/pull/2640 - WIP) I used the work-around but it would still be better to fix this in openldap. Please consider merging the attached patch. --nextPart4704199.6R7aSYJDEk Content-Disposition: attachment; filename="0001-Fixing-8674-Leak-in-ldap_create_assertion_control.patch" Content-Transfer-Encoding: 7Bit Content-Type: text/x-patch; charset="UTF-8"; name="0001-Fixing-8674-Leak-in-ldap_create_assertion_control.patch" >From 59e15d7cd5217312fcc6e3343476416a39cdc739 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?C=C3=B4me=20Chilliet?= <come(a)opensides.be> Date: Thu, 7 Sep 2017 17:11:57 +0200 Subject: [PATCH] Fixing #8674 Leak in ldap_create_assertion_control ldap_create_assertion_control_value was returning ld->ld_errno upon success without reseting it to LDAP_SUCCESS first --- libraries/libldap/assertion.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libraries/libldap/assertion.c b/libraries/libldap/assertion.c index 8ccd5c188..e736d59eb 100644 --- a/libraries/libldap/assertion.c +++ b/libraries/libldap/assertion.c @@ -31,6 +31,8 @@ ldap_create_assertion_control_value( BerElement *ber = NULL; int err; + ld->ld_errno = LDAP_SUCCESS; + if ( assertion == NULL || assertion[ 0 ] == '\0' ) { ld->ld_errno = LDAP_PARAM_ERROR; return ld->ld_errno; -- 2.11.0 --nextPart4704199.6R7aSYJDEk-- --nextPart2367739.nNEjSNJblS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEnJSNrcx2T3JL/3cLqGTYw87LDgAFAlmxaNcACgkQqGTYw87L DgAVJA/+IlrkY3qAMDWe3CqrX4XDwFcA2C3BNzLuPvsymVl2vWNjwn/t7HmpWR2v Hs+mLeTZwe/Z7+zej5H0FujRzHnzaEm3OsGf26mPZeeIRkC1PvE9CLUZzn4M9Mak fejbb2a4EcQnPy7aAD/3Ux2mjJgF2Bl3zc8K0rQO9VSxjpNErt8U2aKgKB+t1QFb /rV4+p/ovRbFydz+RweLBI4+5kuEkWxwfc1JesbjpFNZoEJFv8oCqaRZ3RdU4KQr 6v6+Ku5O9NWp325tXcZ7aW1DQ7BhoVnYAHMl0aLLWvNF95I2yAHaWJAJJ09DooBd 43kLxqcITLuuMg3fIzSeqQs8SEWl5/p3Km64iuAhg4px8+A9Zy//I3mwCI7Qhui8 ZNTrC3cDVBE0Jy5o5QNH1YYEVq65jVvpsm95RhS0PAtN7XsSjRDnvbdinyhdV2oD vtEHivK9B66KcKAxe+c9vluaQB3VImzX2Ji5ceLipGwesHOs6Qj8uaXcYZvopRPz ffbeFFYWDLWJvBZmG/9C1AvPGKEThli8gtsO1JGcFwnv0Wnf1ClBSy8W3qcUtugh pKtBvrUG1aUKogwNZOeg7hdv0nS5joNHRjQT7apD+z1zA0u/uZ8FHn1j/XkQxyXv ArP/jEWsxMRNIaxmZJsVViEFnQNsNoJq7+Z9LBee86cl+IpwNik= =Hdb1 -----END PGP SIGNATURE----- --nextPart2367739.nNEjSNJblS--

1 0

Re: (ITS#8724) slapo-pcache truncates remote results
by quanah＠symas.com 06 Sep '17

06 Sep '17

--On Wednesday, September 06, 2017 7:06 PM -0500 Adam Heath <adam(a)brainfood.com> wrote: > Well, then since you are confirming the bug, I would say this ticket > should *not* be closed. I already reopened it. ;) > I might just have to patch this to make it work. Make sure you follow the contribution guidelines: <https://www.openldap.org/devel/contributing.html> Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8724) slapo-pcache truncates remote results
by adam＠brainfood.com 06 Sep '17

06 Sep '17

I just cloned the source, and found where it removes the paging control. == /* NOTE: this is a quick workaround to let pcache minimally interact * with pagedResults. A more articulated solutions would be to * perform the remote query without control and cache all results, * performing the pagedResults search only within the client * and the proxy. This requires pcache to understand pagedResults. */ static int pcache_chk_controls( Operation *op, SlapReply *rs ) == Well, then since you are confirming the bug, I would say this ticket should *not* be closed. I might just have to patch this to make it work. The client software I'm actually working with is nextcloud, and it is *very* *very* *very* ldap chatty. And with 2900+ objectclass=group, and 3300 objectclass=person, it runs super dog slow. Their suggestion is to install a local ldap instance configured as a caching proxy, which has led us to here. I've already fixed several issues in nextcloud locally(the first one I ran into was $limit=400 hard-coded in the group search function). This kind of paged result handling needs to be dealt the same way an http proxy would deal with partial content caches. On Wed, Sep 6, 2017 at 4:22 PM, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > Hi Adam, > > I would note that pcache is not back-ldap, so their behavior is not the > same. > > slapo-pcache strips out the paged results control, and has since 2005 > (ec532ce88590c5454025cbc030d9df65d2df634f). So in the 12 years since then, > you're the first to have an issue with the behavior. If you'd like to see a > change in relation to this, patches welcome. > > --Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

1 0

Re: (ITS#8724) slapo-pcache truncates remote results (fwd)
by quanah＠symas.com 06 Sep '17

06 Sep '17

Hi Adam, I would note that pcache is not back-ldap, so their behavior is not the same. slapo-pcache strips out the paged results control, and has since 2005 (ec532ce88590c5454025cbc030d9df65d2df634f). So in the 12 years since then, you're the first to have an issue with the behavior. If you'd like to see a change in relation to this, patches welcome. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com> -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8717) Connection delete callback registreed with LDAP_OPT_CONNECT_CB is not called on TLS failure
by hyc＠symas.com 06 Sep '17

06 Sep '17

ipuleston(a)SonicWALL.com wrote: > I have uploaded the patch to ftp.openldap.org/incoming as ian-puleston-1708= > 25.patch, and included it below. > > The code that it adds is pretty much copied from ldap_free_connection: Thanks for the report, added in 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

← Newer
1
...
6
7
8
9
10
11
12
13
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs September 2017