openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Re: (ITS#9055) contrib/slapd-modules/passwd/totp improvements
by gv＠members.scinet.supercomputing.org 31 Jul '19

31 Jul '19

On Wed, Jul 31, 2019 at 03:25:21PM +0100, Howard Chu wrote: > I've been looking for a way to support the hashing callbacks. Without them, > this won't be accepted. > > Easiest at this point is simply to define a character (maybe space, or tab) > as a delimiter between seed and password. Thanks Howard. I was trying to stay away from that as it would make it somewhat confusing to use that character, but if you think it's OK to implement that way I'll give it a shot. I'll just make sure it's well documented in the manpage as well... -- Greg Veldman

1 0

Re: (ITS#9055) contrib/slapd-modules/passwd/totp improvements
by hyc＠symas.com 31 Jul '19

31 Jul '19

gv(a)members.scinet.supercomputing.org wrote: > On Fri, Jul 19, 2019 at 04:08:13PM -0400, Greg Veldman wrote: >> Updated patch: >> >> https://scinet.supercomputing.org/~gv/slapd-totp-v2.txt > > I don't mean to push too hard on this because I know everyone's > busy, but it has been almost two weeks. If anyone sees any > outstanding issues with v2 of the patch, I'd be happy to implement > any further changes to get it to an acceptable state. If not, > can this change either be merged or rejected outright so the issue > can be closed out? I've been looking for a way to support the hashing callbacks. Without them, this won't be accepted. Easiest at this point is simply to define a character (maybe space, or tab) as a delimiter between seed and password. -- -- 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#9055) contrib/slapd-modules/passwd/totp improvements
by gv＠members.scinet.supercomputing.org 31 Jul '19

31 Jul '19

On Fri, Jul 19, 2019 at 04:08:13PM -0400, Greg Veldman wrote: > Updated patch: > > https://scinet.supercomputing.org/~gv/slapd-totp-v2.txt I don't mean to push too hard on this because I know everyone's busy, but it has been almost two weeks. If anyone sees any outstanding issues with v2 of the patch, I'd be happy to implement any further changes to get it to an acceptable state. If not, can this change either be merged or rejected outright so the issue can be closed out? Thanks. -- Greg Veldman

1 0

Re: (ITS#9037) observing crash in mdb_cursor_put()
by vporof＠mozilla.com 31 Jul '19

31 Jul '19

Hey folks. =46rom Myk=E2=80=99s investigations in the previous followup, it seems = that the suggested changes to `mdb_cursor_init` to avoid using an = invalid DBI might not be solving the actual issue, given the behaviour = of `mdb_page_search`. It=E2=80=99s also causing the seemingly correct test program to assert = when it wasn=E2=80=99t before. It=E2=80=99s unclear whether this should = be the case or not, perhaps Howard can confirm the expected behaviour. In any case, we=E2=80=99re wondering if there=E2=80=99s been any other = progress, or if someone managed to reproduce this issue? Shipping new = features built on top of LMDB in Firefox is currently blocked due to = these failures, so any additional info would be helpful. Victor

1 0

(ITS#9058) [PATCH]Fix implicit function declaration
by rosenp＠gmail.com 31 Jul '19

31 Jul '19

Full_Name: Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.14.106.55) --- a/libraries/libldap/tls2.c +++ b/libraries/libldap/tls2.c @@ -41,6 +41,7 @@ static tls_impl *tls_imp = &ldap_int_tls_impl; #define HAS_TLS( sb ) ber_sockbuf_ctrl( sb, LBER_SB_OPT_HAS_IO, \ (void *)tls_imp->ti_sbio ) +static int ldap_pvt_tls_check_hostname( LDAP *ld, void *s, const char *name_in ); #endif /* HAVE_TLS */ #ifdef LDAP_DEVEL

1 0

(ITS#9057) Makefile:291: recipe for target 'mdb-yes' failed
by lzy110100＠aliyun.com 30 Jul '19

30 Jul '19

Full_Name: Yon Liu Version: git://git.openldap.org/openldap.git (clone at 20190729) OS: Ubuntu18.04 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (59.37.4.228) info: ubuntu:18.04 openldap: git://git.openldap.org/openldap.git(clone at 20190729) steps: (reference: http://www.openldap.org/software/release/install.html) ./configure make depend make make test issue: (partial log) >>>>> test067-tls completed OK for mdb. >>>>> Starting test068-sasl-tls-external for mdb... running defines.sh Running slapadd to build slapd database... Starting ldap:/// slapd on TCP/IP port 9011 and ldaps:/// slapd on 9012... Using ldapwhoami with SASL/EXTERNAL....ldapwhoami (startTLS) failed (1)! >>>>> test068-sasl-tls-external failed for mdb (exit 1) Makefile:291: recipe for target 'mdb-yes' failed make[2]: *** [mdb-yes] Error 1 make[2]: Leaving directory '/home/bl/openldap/tests' Makefile:279: recipe for target 'test' failed make[1]: *** [test] Error 2 make[1]: Leaving directory '/home/bl/openldap/tests' Makefile:293: recipe for target 'test' failed make: *** [test] Error 2

1 0

Re: (ITS#7657) Alias dereferencing with MDB slow compared with BDB
by hyc＠symas.com 26 Jul '19

26 Jul '19

Mark.Cairney(a)ed.ac.uk wrote: > Hi Howard, Hi Mark, thanks for the feedback. For completeness' sake, the tool I used to generate our test dataset is in http://www.openldap.org/its/index.cgi?findid=8875#followup14 > > Just to confirm that I'm seeing significantly better results with the > 2.4.48 RC release for querying OUs full of aliases and de-referencing them: > > Comparing 2 servers with the same data on them (one 2.4.47, the other > 2.4.48 with the new patch) and just after restarting slapd yield the > following: > > 2.4.48: 0.52s user 0.09s system 46% cpu 1.315 total (with a small spike > in CPU) > > 2.4.47: 0.46s user 0.94s system 0% cpu 3:39.89 total (with the CPU > spiking to 100% on the server for the duration of the query) > > > This is for an OU with 11932 entries in it (all aliasedObjects) > > On 15/07/2019 17:07, Howard Chu wrote: >> Fyi, we recently revisited this issue and are seeing improved results with >> commit e90e8c7d3c12d897bb0584ba04dc519d4f23acf9 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

Re: (ITS#7657) Alias dereferencing with MDB slow compared with BDB
by Mark.Cairney＠ed.ac.uk 26 Jul '19

26 Jul '19

Hi Howard, Just to confirm that I'm seeing significantly better results with the 2.4.48 RC release for querying OUs full of aliases and de-referencing them: Comparing 2 servers with the same data on them (one 2.4.47, the other 2.4.48 with the new patch) and just after restarting slapd yield the following: 2.4.48: 0.52s user 0.09s system 46% cpu 1.315 total (with a small spike in CPU) 2.4.47: 0.46s user 0.94s system 0% cpu 3:39.89 total (with the CPU spiking to 100% on the server for the duration of the query) This is for an OU with 11932 entries in it (all aliasedObjects) On 15/07/2019 17:07, Howard Chu wrote: > Fyi, we recently revisited this issue and are seeing improved results with > commit e90e8c7d3c12d897bb0584ba04dc519d4f23acf9 in master. > -- /**************************** Mark Cairney ITI Enterprise Services Information Services University of Edinburgh Tel: 0131 650 6565 Email: Mark.Cairney(a)ed.ac.uk PGP: 0x435A9621 *******************************/ The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

Re: (ITS#9052) ACL protections get lost if same identity uses different SSF levels
by quanah＠symas.com 25 Jul '19

25 Jul '19

--On Wednesday, July 24, 2019 3:45 PM -0700 Quanah Gibson-Mount <quanah(a)symas.com> wrote: > For informational purposes, here's additional detail as the subject and > original problem description do not fully capture the extend of the > problem. In all 2.x releases prior to 2.4.48 (I.e., 2.0.x, 2.1.x, 2.2.x, > 2.3.x, and 2.4.x up to 2.4.47), the SASL security factor layer was set > globally rather than per connection. So once a connection had been made > that sets a SASL SSF, any and all non SASL connections would inherit that > value. Correction -- sasl SSF was set per connection structure. Any new client connection that used the same connection structure as a previous connection would inherit the sasl_ssf value of the prior connection. In slapd, one can generally tell which connection structure is being used by looking at the file descriptor in use by a given connection (stats level logging will display this information, for example). On a busy server where connection structures are routinly being re-used then there is a high probability that this would apply to most connections as long as the majority of connections are setting SASL SSF values. --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#9052) ACL protections get lost if same identity uses different SSF levels
by quanah＠symas.com 24 Jul '19

24 Jul '19

For informational purposes, here's additional detail as the subject and original problem description do not fully capture the extend of the problem. In all 2.x releases prior to 2.4.48 (I.e., 2.0.x, 2.1.x, 2.2.x, 2.3.x, and 2.4.x up to 2.4.47), the SASL security factor layer was set globally rather than per connection. So once a connection had been made that sets a SASL SSF, any and all non SASL connections would inherit that value. If ACLs are used to limit access via setting restrictions with the sasl_ssf parameter, connections with no sasl_ssf could match those ACLs incorrectly. For example, access to * by users sasl_ssf=56 read by users tls_ssf=128 read by * none Would allow a user who bound without any encryption full access to the database as long as one SASL connection had been made that had a minimum sasl_ssf value of 56. Another contrived example: access to attrs=userPassword by self sasl_ssf=56 =xw by * auth Would allow a user to change their own password whether or not they had performed a SASL bind with a sasl_ssf of 56. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

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