openldap-bugs July 2020

openldap-bugs@openldap.org

2 participants
123 discussions

[Bug 9246] New: Improve authzFrom/authzTo docs
by openldap-its＠openldap.org 26 Feb '21

26 Feb '21

https://bugs.openldap.org/show_bug.cgi?id=9246 Bug ID: 9246 Summary: Improve authzFrom/authzTo docs Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: kop(a)karlpinc.com Target Milestone: --- Created attachment 724 --> https://bugs.openldap.org/attachment.cgi?id=724&action=edit Patch The defaults for group/objectclass/attributetype were not documented. Improve the section overall. I, Karl O. Pinc, 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. -- You are receiving this mail because: You are on the CC list for the bug.

1 9

[Issue 9283] New: Mutex leak in backend.c`backend_db_init()
by openldap-its＠openldap.org 25 Feb '21

25 Feb '21

https://bugs.openldap.org/show_bug.cgi?id=9283 Issue ID: 9283 Summary: Mutex leak in backend.c`backend_db_init() Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: grapvar(a)gmail.com Target Milestone: --- @backend_db_init: if bi_db_init() fails, but [BackendDB *be] is not listed in [slap_be_head backendDB] list of backends, then be->be_pcl_mutex is not destroyed. | BackendDB * | backend_db_init( ... ) | { | ... | ldap_pvt_thread_mutex_init( &be->be_pcl_mutex ); | ... | if ( bi->bi_db_init ) | rc = bi->bi_db_init( be, cr ); | | if ( rc != 0 ) { | if ( !b0 ) { | ... | ldap_pvt_thread_mutex_destroy( &be->be_pcl_mutex ); | ch_free( be ); Additionally, it does not look like that owner of [b0] cares about destroying this mutex. -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 9293] New: slapo-ppolicy stores pwdGraceUseTime only with seconds
by openldap-its＠openldap.org 24 Feb '21

24 Feb '21

https://bugs.openldap.org/show_bug.cgi?id=9293 Issue ID: 9293 Summary: slapo-ppolicy stores pwdGraceUseTime only with seconds Product: OpenLDAP Version: 2.4.50 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: michael(a)stroeder.com Target Milestone: --- If password is expired slapo-ppolicy can return the number of grace logins for changing own password (graceAuthNsRemaining). slapd derives graceAuthNsRemaining from number of pwdGraceUseTime values. But those timestamps are only stored with a granularity of a second. Thus multiple grace logins are possible within a second without decremeting graceAuthNsRemaining value. This is unexpected and also leads to absurd work-arounds when writing automated tests like this: https://gitlab.com/ae-dir/python-ldap0/-/blob/master/tests/test_ppolicy.py#… Either a real Integer counter should be used or fraction of seconds should be used in pwdGraceUseTime values. This is a similar problem like pwdFailureTime solved in ITS#7161. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Bug 9205] New: Openldap 2.4.49 with overlays syncrepl+ppolicy+chain+ldap
by openldap-its＠openldap.org 01 Feb '21

01 Feb '21

https://bugs.openldap.org/show_bug.cgi?id=9205 Bug ID: 9205 Summary: Openldap 2.4.49 with overlays syncrepl+ppolicy+chain+ldap Product: OpenLDAP Version: 2.4.49 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: frederic.poisson(a)admin.gmessaging.net Target Milestone: --- Created attachment 700 --> https://bugs.openldap.org/attachment.cgi?id=700&action=edit test script copied from test022-ppolicy and modified to show the trouble Hello, I'm doing a OpenLDAP test with a master/slave replication configuration including ppolicy overlay. I would like to enable password change from the slave replica with chain overlay, in order to validate the ppolicy olcPPolicyForwardUpdates attribute to TRUE. I'm using LDAPS from slave to master with SASL External authentication with client certificate. The client certificate correspond to a user DN entry with "manage" rights on the master server (the same used for the replication). This user DN has authzTo attribute in order to match the correct PROXYAUTHZ request from its dn to user DN. All of this configuration works on replica when i do first a failed authentication (err=49) on replica. The pwdFailureTime value is updated on the DN entry from replica to slave normally. I'm also able to do after some self entry update on some attribute such as password or others from replica to master. But the weird behavior is that i need to run first an failed authentication, otherwise if i try to change attribute on the slave server, it respond an err=80 "Error: ldap_back_is_proxy_authz returned 0, misconfigured URI?". The only way to retrieve correct behavior is to restart slapd, and redo one failed authentication first. It seems that the chain overlay do not connect the master server at startup. I've done a modification of test script test022-ppolicy to test022-policy-chain which use the same LDIF source and show the problem of modification on the consumer not "relayed" to the supplier if a fail operation is not done before. Regards -- You are receiving this mail because: You are on the CC list for the bug.

1 12

[Bug 9222] New: Fix presence list to use a btree instead of an AVL tree
by openldap-its＠openldap.org 21 Jan '21

21 Jan '21

https://bugs.openldap.org/show_bug.cgi?id=9222 Bug ID: 9222 Summary: Fix presence list to use a btree instead of an AVL tree Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- [23:34] <hyc> ok, so far heap profile shows that memory use during refresh is normal [23:35] <hyc> not wonderful, but normal. mem usage grows because we're recording the present list while receiving entries in the refresh [23:36] <hyc> I'm seeing for 1.2GB of data about 235MB of presentlist [23:36] <hyc> which is pretty awful, considering presentlist is just a list of UUIDs [23:36] <hyc> being stored in an avl tree [23:37] <hyc> a btree would have been better here, and we could just use an unsorted segmented array [23:42] <hyc> for the accumulation phase anyway. we need to be able to lookup records during the delete pphase [00:05] <hyc> this stuff seriously needs a rewrite [01:13] <hyc> 2.8M records x 16 bytes per uuid so this should be no more than 48MB of overhead [01:13] <hyc> and instead it's 3-400MB -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Issue 6036] Crash: UUIDNormalize doesn't clear output on error
by openldap-its＠openldap.org 05 Dec '20

05 Dec '20

https://bugs.openldap.org/show_bug.cgi?id=6036 --- Comment #5 from amez365 <fieldengineer59(a)yahoo.com> --- Infrastructure Engineer https://www.fieldengineer.com/skills/what-is-an-infrastructure-engineer Infrastructure Engineer's roles include being responsible for designing, building, implementing and maintaining the IT infrastructure using the latest technology. An IT infrastructure engineer ensures that all IT systems that support businesses of any size operate efficiently. https://www.fieldengineer.com/skills/what-is-an-infrastructure-engineer -- You are receiving this mail because: You are on the CC list for the issue.

4 3

[Issue 9280] New: A read-only ppolicy installation
by openldap-its＠openldap.org 14 Oct '20

14 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=9280 Issue ID: 9280 Summary: A read-only ppolicy installation Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- There might be environments where letting ppolicy write into the local database is not appropriate, but neither is chaining. It should be possible to skip the modifications altogether. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9264] New: Add lock to slapo-unique to delay new ops until current op is complete
by openldap-its＠openldap.org 14 Oct '20

14 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=9264 Issue ID: 9264 Summary: Add lock to slapo-unique to delay new ops until current op is complete Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: gnoe(a)symas.com Target Milestone: --- Locking is needed in slapo-unique to prevent duplicate values when new operations are started before previous operations are completed. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Bug 9242] New: build failure with OpenSSL 0.9.7: EVP_sha256() undefined
by openldap-its＠openldap.org 14 Oct '20

14 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=9242 Bug ID: 9242 Summary: build failure with OpenSSL 0.9.7: EVP_sha256() undefined Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: ryan(a)openldap.org Target Milestone: --- git master fails to build with OpenSSL 0.9.7d: $ openssl version OpenSSL 0.9.7d 17 Mar 2004 (+ security fixes for: CVE-2005-2969 CVE-2006-2937 CVE-2006-2940 CVE-2006-3738 CVE-2006-4339 CVE-2006-4343 CVE-2006-7250 CVE-2007-5135 CVE-2007-3108 CVE-2008-5077 CVE-2008-7270 CVE-2009-0590 CVE-2009-2409 CVE-2009-3555 CVE-2010-4180 CVE-2011-4576 CVE-2011-4619 CVE-2012-0884 CVE-2012-1165 CVE-2012-2110 CVE-2012-2131 CVE-2012-2333) $ ./configure --with-tls=openssl --disable-slapd && make [...] libtool: link: gcc -g -O2 -o apitest apitest.o -L/usr/sfw/lib ./.libs/libldap.a /export/home/ryan/openldap/libraries/liblber/.libs/liblber.a ../../libraries/liblber/.libs/liblber.a ../../libraries/liblutil/liblutil.a -lsasl -lssl -lcrypto -lresolv -lgen -lnsl -lsocket -R/usr/sfw/lib Undefined first referenced symbol in file EVP_sha256 ./.libs/libldap.a(tls_o.o) ld: fatal: symbol referencing errors. No output written to apitest collect2: ld returned 1 exit status *** Error code 1 The SHA-2 algorithms were first added in OpenSSL 0.9.8. If the use of EVP_sha256() is to be unconditional, please make configure fail if an older version is detected, and update the documentation as well (i.e. admin guide for 2.5). (This could also be an opportunity to make the CRL feature unconditional; currently it is enabled only with OpenSSL 0.9.7d or later.) -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 9239] New: test007 failed on Solaris 10: slapmodify crashed
by openldap-its＠openldap.org 14 Oct '20

14 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=9239 Bug ID: 9239 Summary: test007 failed on Solaris 10: slapmodify crashed Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ryan(a)openldap.org Target Milestone: --- ./configure CPPFLAGS=-I/opt/csw/include LDFLAGS="-L/opt/csw/lib -R/opt/csw/lib" && make && make check >>>>> Starting test007-slapmodify for mdb... running defines.sh Running slapadd to build slapd database... Testing modify, add, and delete using slapmodify... Segmentation Fault - core dumped slapmodify failed (139)! >>>>> test007-slapmodify failed for mdb after $(( %s - %s )) seconds (exit 139) -bash-3.2$ dbx servers/slapd/slapd tests/core [...] program terminated by signal SEGV (no mapping at the fault address) 0xfead646c: strlen+0x000c: movl (%eax),%edx Current function is lutil_debug 74 len = vsnprintf( buffer+off, sizeof(buffer)-off, fmt, vl ); (dbx) where [1] strlen(0x0), at 0xfead646c [2] _ndoprnt(0x823a44b, 0x8046ebc, 0x8045e60, 0x0), at 0xfeb31bce [3] vsnprintf(0x8045e99, 0xff7, 0x823a430, 0x8046ebc), at 0xfeb34d8f =>[4] lutil_debug(debug = 16645, level = 1, fmt = 0x823a430 "oc_check_required entry (%s), objectClass "%s"\n", ... = <value unavailable>, ...), line 74 in "debug.c" [5] oc_check_required(e = 0x8534ad4, oc = 0x831a890, ocname = 0x852a1b8), line 514 in "schema_check.c" [6] entry_schema_check(op = 0x804718c, e = 0x8534ad4, oldattrs = (nil), manage = 0, add = 1, socp = (nil), text = 0x80475d0, textbuf = 0x804708c "", textlen = 256U), line 430 in "schema_check.c" [7] slap_tool_entry_check(progname = 0x824a964 "slapmodify", op = 0x804718c, e = 0x8534ad4, lineno = 3, text = 0x80475d0, textbuf = 0x804708c "", textlen = 256U), line 1186 in "slapcommon.c" [8] slapmodify(argc = 10, argv = 0x8047838), line 446 in "slapmodify.c" [9] main(argc = 10, argv = 0x8047838), line 670 in "main.c" (dbx) up Current function is oc_check_required 514 Debug( LDAP_DEBUG_TRACE, (dbx) list 514 Debug( LDAP_DEBUG_TRACE, 515 "oc_check_required entry (%s), objectClass \"%s\"\n", 516 e->e_dn, ocname->bv_val ); 517 518 519 /* check for empty oc_required */ 520 if(oc->soc_required == NULL) { 521 return NULL; 522 } 523 (dbx) print e->e_dn e->e_dn = (nil) (dbx) print ocname->bv_val ocname->bv_val = 0x852a1a0 "OpenLDAPperson" On other systems, the debug output is: 5ea0dcca oc_check_required entry ((null)), objectClass "OpenLDAPperson" It appears this version of vsnprintf cannot handle the %s argument being NULL. -- You are receiving this mail because: You are on the CC list for the bug.

1 7

← Newer
1
2
3
4
5
6
7
8
...
13
Older →

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs July 2020