- openldap-bugs - openldap.org

[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

[Issue 10076] New: suffixmassage in back-asyncmeta does not handle empty remote suffix correctly
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10076 Issue ID: 10076 Summary: suffixmassage in back-asyncmeta does not handle empty remote suffix correctly Product: OpenLDAP Version: 2.6.4 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- When configuring a suffixmassage directive on an asyncmeta database, a configuration like: suffixmassage "dc=example,dc=com" "" causes search requests to return error 34 "Invalid DN", because the empty remote suffix is massaged incorrectly, adding an unnecessary ",". The issue applies only to asyncmeta, on other proxies it functions correctly. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10139] back-config discloses existence of entries contrary to ACL
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10139 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED Group|OpenLDAP-devs | -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7420] Possible to bypass overlay unique and constraint
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=7420 --- Comment #11 from Quanah Gibson-Mount <quanah(a)openldap.org> --- commit d56dcccb6f6cfd590eb20628eec39ab815a65f5a Author: Howard Chu <hyc(a)openldap.org> Date: Sun Jan 28 04:43:44 2024 +0000 ITS#7420 clarify prev commit commit 03338946b3e165e3c703c57cede266c42418cc1f Author: Howard Chu <hyc(a)openldap.org> Date: Sun Jan 28 04:00:34 2024 +0000 ITS#7420 more for prev commit On naming error, don't free modvals -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8618] Remove deprecated -h HOST and -p PORT options from clients
by openldap-its＠openldap.org 25 Jan '24

25 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=8618 --- Comment #28 from Quanah Gibson-Mount <quanah(a)openldap.org> --- (In reply to Quanah Gibson-Mount from comment #27) > (In reply to Quanah Gibson-Mount from comment #26) > > Additionally, this was clearly documented in the UPGRADE section of the Admin guide. > > Specifically, in the OpenLDAP 2.5 admin guide section on upgrading from > OpenLDAP 2.4 or prior releases. https://www.openldap.org/doc/admin25/appendix-upgrading.html#Client%20utili… -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8618] Remove deprecated -h HOST and -p PORT options from clients
by openldap-its＠openldap.org 25 Jan '24

25 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=8618 --- Comment #27 from Quanah Gibson-Mount <quanah(a)openldap.org> --- (In reply to Quanah Gibson-Mount from comment #26) > Additionally, this was clearly documented in the UPGRADE section of the Admin guide. Specifically, in the OpenLDAP 2.5 admin guide section on upgrading from OpenLDAP 2.4 or prior releases. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8618] Remove deprecated -h HOST and -p PORT options from clients
by openldap-its＠openldap.org 25 Jan '24

25 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=8618 --- Comment #26 from Quanah Gibson-Mount <quanah(a)openldap.org> --- (In reply to jel+git from comment #23) > 1) If one decides to drop an option, it should be > a) communicated clearly. > b) documented and alternatives shown Hello, The options were *clearly* marked as deprecated for the last 24 years in the man pages for the ldap client utilities. It appears whomever wrote the scripts in question chose to ignore this clearly documented deprecation of the options and used them anyway. Additionally, this was clearly documented in the UPGRADE section of the Admin guide. In other words, this change has been clearly communicated for years, and well documented. Perhaps in the future it would be wise to read the supplied upgrade documentation prior to performing an upgrade of software and to pay attention to deprecation notices in the software documentation instead of attacking a volunteer powered open source software project. Regards, Quanah -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10159] New: Unable to Use ldapi:// - ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)
by openldap-its＠openldap.org 24 Jan '24

24 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10159 Issue ID: 10159 Summary: Unable to Use ldapi:// - ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1) Product: OpenLDAP Version: 2.5.13 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: chilimili1(a)outlook.de Target Milestone: --- Problem: When attempting to use the ldapi:// URI to interact with the OpenLDAP server using commands like ldapmodify or ldapsearch, an error is encountered: ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1). Process is running # ps -aux |grep ldap ldap 9 0.0 0.4 42232968 79472 ? Sl Jan23 0:10 /usr/libexec/slapd -u ldap -h ldap:/// ldapi:/// ldaps:/// -F /etc/openldap/slapd.d -d 256 Troubleshooting Steps Taken: Verified the ldapi URI configuration. Inspected the OpenLDAP configuration using slapd.conf or cn=config. Examined ACLs and access control rules. Additional Information: OpenLDAP is running as a Docker container Docker Compose configuration includes port mappings for LDAP (3269:389) and LDAPS (3268:636). The whole configuration was migrated from a working Server Any additional insights or recommendations for resolving the ldapi connection issue would be greatly appreciated. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 8618] Remove deprecated -h HOST and -p PORT options from clients
by openldap-its＠openldap.org 24 Jan '24

24 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=8618 --- Comment #25 from Howard Chu <hyc(a)openldap.org> --- Also: the time to raise objections to a change is before the release. The 2.5 call for testing went out in April 2021. https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/… You're about 3 years late complaining about the removal of a feature deprecated 24 years ago. Demanding that volunteers work on what you want the way you want won't fly. Only people who are actively involved will have their concerns listened to. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8618] Remove deprecated -h HOST and -p PORT options from clients
by openldap-its＠openldap.org 24 Jan '24

24 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=8618 --- Comment #24 from Howard Chu <hyc(a)openldap.org> --- A reminder that the OpenLDAP Project is worked solely by volunteers. Symas does not direct the operation of the Project. They merely provide support for what the Project releases. Your criticism of Symas is wholly out of place. Meanwhile, criticizing work that was given to you for free, without you ever lifting a finger to contribute, just makes you a selfish, entitled, ungrateful ass. If you think you can run things better, then actively contribute. That is the only way that open source projects advance. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8618] Remove deprecated -h HOST and -p PORT options from clients
by openldap-its＠openldap.org 24 Jan '24

24 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=8618 --- Comment #23 from jel+git(a)linofee.org --- Just upgraded a server from Ubuntu 20.04 to 22.04, which contains 2.5.x and found out, that the options -p and -h got dropped - and requires me to adjust quite a bit of scripts because of this non-sense. This is such a poor software management and versioning, hard to believe, that anyone who allowed it to go through, has any experience in enterprise ready software. 1) If one decides to drop an option, it should be a) communicated clearly. b) documented and alternatives shown 2) If a software gets released, which has an incompatible change wrt. previous major.minor.tiny version, it should rise the major number of the software version, so that OS/Distro vendors are warned and may decide to stick with the old version. There are several options to allow -H and -h,-p side by side - openldap has chosen the worst option. This might be a hint, how poor its maintenance actually is/how bad the support by sysmas probably is. This is also a good example, that for OS/Distro vendors it is sometimes a really good thing to stick with the older version instead of switching to the "latest" stuff. Anyway, thanx for the work. =8-( -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10158] New: Linker error when building openldap-2.4.59
by openldap-its＠openldap.org 23 Jan '24

23 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10158 Issue ID: 10158 Summary: Linker error when building openldap-2.4.59 Product: OpenLDAP Version: 2.4.59 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: umagmrit(a)gmail.com Target Milestone: --- -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10013] New: Some code (ppolicy, etc.) ignores REP_CTRLS_MUSTBEFREED when touching rs->sr_ctrls
by openldap-its＠openldap.org 17 Jan '24

17 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10013 Issue ID: 10013 Summary: Some code (ppolicy, etc.) ignores REP_CTRLS_MUSTBEFREED when touching rs->sr_ctrls Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Certain parts of the source indicate that rs->sr_ctrls shouldn't be realloc'd/free'd unless REP_CTRLS_MUSTBEFREED is set, but then other parts of slapd (slap_ctrl_whatFailed_add, glue_op_search?, ...) and overlays (ppolicy, syncprov, ...) will blindly overwrite and/or realloc it. slap_add_control() (an analog of slap_add_controls()) might be useful for this, possibly alongside some way to free the other data kept around to streamline the code other users need for correct operation. -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 9944] New: Reverting an olcDbACLBind statement breaks proxied write operations
by openldap-its＠openldap.org 16 Jan '24

16 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=9944 Issue ID: 9944 Summary: Reverting an olcDbACLBind statement breaks proxied write operations Product: OpenLDAP Version: 2.6.3 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: --- On a system with olcDbIDAssertBind configured, and proxied authorizations working correctly, an olcDbACLBind statement was added to the configuration for lastbind support. However an incorrect identity was in place for the authzid in the ACL bind statement which caused proxy authorization to fail. The change was backed out (There was never any change to the olcDbIDAssertBind config fragment) and after that, all write operations failed instead of being proxied, with err=80. Restarting slapd fixed the issue, which indicates an underlying problem in the cn=config db in reverting to the original working state. -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 10151] New: Leaks in do_syncrep2() when error handling
by openldap-its＠openldap.org 16 Jan '24

16 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10151 Issue ID: 10151 Summary: Leaks in do_syncrep2() when error handling Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Investigating the persistent CI failures in test050, I can see some memory leaks that should be tackled (if only to reduce noise). For one, when receiving an entry without a syncrepl control attached or when dealing with a concurrent thread removing that consumer, we leak our scratch data (decoded controls, modlist, ...). -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10137] New: Ease redefining the MDB_IDL_LOGN value
by openldap-its＠openldap.org 16 Jan '24

16 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10137 Issue ID: 10137 Summary: Ease redefining the MDB_IDL_LOGN value Product: LMDB Version: 0.9.30 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: renault.cle(a)gmail.com Target Milestone: --- Created attachment 992 --> https://bugs.openldap.org/attachment.cgi?id=992&action=edit The patch do apply to midl.h Hello, I would like to slightly change the midl.h c file to make it possible to change the MDB_IDL_LOGN define without having to fork on my side. I know it can be redefined to reduce the amount of memory allocated by LMDB. I am using the latest `mdb.master` branch version of LMDB. https://github.com/mozilla/lmdb/pull/2 -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 10157] New: mdb_load doesn't build for me
by openldap-its＠openldap.org 16 Jan '24

16 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10157 Issue ID: 10157 Summary: mdb_load doesn't build for me Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: tools Assignee: bugs(a)openldap.org Reporter: vl(a)samba.org Target Milestone: --- Created attachment 1001 --> https://bugs.openldap.org/attachment.cgi?id=1001&action=edit Patch see attached patch -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 7420] Possible to bypass overlay unique and constraint
by openldap-its＠openldap.org 16 Jan '24

16 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=7420 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|IN_PROGRESS |RESOLVED --- Comment #10 from Quanah Gibson-Mount <quanah(a)openldap.org> --- • f5c96f44 by Howard Chu at 2024-01-10T17:05:13+00:00 ITS#7420 move entry_naming_check earlier in Add • 7debe76f by Howard Chu at 2024-01-15T16:43:56+00:00 ITS#7420 re-fix slapcommon.c -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10154] New: Configure auto close for pull requests created on github
by openldap-its＠openldap.org 16 Jan '24

16 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10154 Issue ID: 10154 Summary: Configure auto close for pull requests created on github Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Configure the auto close action for PRs created on Github. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 7420] Possible to bypass overlay unique and constraint
by openldap-its＠openldap.org 15 Jan '24

15 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=7420 --- Comment #9 from Howard Chu <hyc(a)openldap.org> --- (In reply to Ondřej Kuzník from comment #8) > The patch in MR!665 (now in master) has introduced a regression in slapadd > not filling in the implicit RDN attributes. Try removing line 7 > (olcDatabase: {0}config) in tests/data/slapd-dynamic.ldif and run test062. I see, the naming check needed to happen before the schema check. Fixed now in master. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7420] Possible to bypass overlay unique and constraint
by openldap-its＠openldap.org 15 Jan '24

15 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=7420 --- Comment #8 from Ondřej Kuzník <ondra(a)mistotebe.net> --- The patch in MR!665 (now in master) has introduced a regression in slapadd not filling in the implicit RDN attributes. Try removing line 7 (olcDatabase: {0}config) in tests/data/slapd-dynamic.ldif and run test062. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10156] New: Any recorded crash-consistency bugs/vulnerabilities in LMDB for study?
by openldap-its＠openldap.org 14 Jan '24

14 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10156 Issue ID: 10156 Summary: Any recorded crash-consistency bugs/vulnerabilities in LMDB for study? Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: yilegu(a)cs.washington.edu Target Milestone: --- Dear LMDB developers, Hello! I am Michael Gu, a CS PhD student at the University of Washington, advised by Prof. Baris Kasikci. We are building a software testing tool that can test the crash-consistency of POSIX applications. The tool also supports testing MMIO-based applications and we think LMDB is a perfect evaluation target. We are wondering if there are any recorded crash consistency bugs/vulnerabilities during the development of the LMDB database. If so, could you kindly provide some pointers to which version of the LMDB database has such issues and if possible the Github commit or Issue ID on OpenLDAP issue tracking system correspondingly? Thank you so much in advance! Bests, Michael Gu ----------------- Yile (Michael) Gu CSE Ph.D. Student University of Washington -- Paul G. Allen School of Computer Science & Engineering yilegu(a)cs.washington.edu -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 8826] Contrib dsaschema module needs updating for cn=config
by openldap-its＠openldap.org 12 Jan '24

12 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=8826 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|IN_PROGRESS |RESOLVED Resolution|--- |FIXED --- Comment #2 from Quanah Gibson-Mount <quanah(a)openldap.org> --- • 69a4a03a by Ondřej Kuzník at 2023-12-05T16:56:29+00:00 ITS#8826 Allow minimal dsaschema configuration in cn=config -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8852] slapd memory use grows continuously with non-delta syncrepl and modifying groups
by openldap-its＠openldap.org 12 Jan '24

12 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=8852 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #9 from Quanah Gibson-Mount <quanah(a)openldap.org> --- • 8986f99d by Ondřej Kuzník at 2023-11-14T18:09:10+00:00 ITS#8852 Optimise attr_cmp for sortval attributes -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8180] back-sock should not return sucess in case of error
by openldap-its＠openldap.org 12 Jan '24

12 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=8180 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|IN_PROGRESS |RESOLVED Resolution|--- |FIXED --- Comment #3 from Quanah Gibson-Mount <quanah(a)openldap.org> --- • 64789dd2 by Howard Chu at 2023-11-14T17:02:18+00:00 ITS#8180 back-sock: return error when str2entry fails • 66edd345 by Howard Chu at 2023-11-14T17:02:18+00:00 ITS#8677 back-sock: return error for CONTINUE -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9660] New: back-mdb Permission denied => Restore from backup
by openldap-its＠openldap.org 12 Jan '24

12 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=9660 Issue ID: 9660 Summary: back-mdb Permission denied => Restore from backup Product: OpenLDAP Version: 2.5.7 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: geert.hendrickx(a)telenetgroup.be Target Milestone: --- Cosmetic issue: When an mdb database has incorrect ownership or permissions (typically after slapadd as root), back-mdb fails with: mdb_db_open: database "dc=my-domain,dc=com" cannot be opened: Permission denied (13). Restore from backup! "Permission denied" is correct, but "Restore from backup" is maybe not the most appropriate advice. ;-) -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10150] New: liblber/etest.c calls open with O_CREAT without specifying file mode
by openldap-its＠openldap.org 12 Jan '24

12 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10150 Issue ID: 10150 Summary: liblber/etest.c calls open with O_CREAT without specifying file mode Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: alan.coopersmith(a)oracle.com Target Milestone: --- https://git.openldap.org/openldap/openldap/-/blob/OPENLDAP_REL_ENG_2_6_6/li… has this call to the open() function: if (( fd = open( "lber-test", O_WRONLY|O_CREAT|O_TRUNC|O_BINARY )) Since O_CREAT is specified, there should be a third argument specifying the file permissions for the newly created file, but it is missing here, which may cause the file to be created with permissions based on whatever noise is in the register or stack position the call reads the third argument from on a given platform. Fortunately, it looks like this code may never be compiled, since it's inside #ifdef HAVE_CONSOLE_H and I can't find anywhere that is set, since it's not in any AC_CONFIG_HEADER checks in the configure.ac file. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10125] New: mdb_load: fix loading in Append mode
by openldap-its＠openldap.org 11 Jan '24

11 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10125 Issue ID: 10125 Summary: mdb_load: fix loading in Append mode Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: tools Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- After committing/flushing a batch of writes, the cursor is not correctly reinitialized in Append mode. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 8498] slapadd complains about missing attrs
by openldap-its＠openldap.org 11 Jan '24

11 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=8498 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|TEST |FIXED --- Comment #6 from Quanah Gibson-Mount <quanah(a)openldap.org> --- head: • 2939df1a by Howard Chu at 2023-11-02T16:53:26+00:00 ITS#8498 slapadd: silence warning for NULL entry -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10148] New: About
by openldap-its＠openldap.org 26 Dec '23

26 Dec '23

https://bugs.openldap.org/show_bug.cgi?id=10148 Issue ID: 10148 Summary: About Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: pinkilhagency(a)gmail.com Target Milestone: --- Welcome to LH Talent Agency, a leading provider of live hosting talent for events and productions. In the fast-paced world of live hosting, finding the perfect individual to engage and captivate your audience is crucial. That's where LH Talent Agency comes in. With our extensive network of experienced and dynamic hosts, we can match you with the perfect talent to ensure your event is a success. Whether you need a skilled emcee, a charismatic presenter, or a engaging host, LH Talent Agency has the expertise and resources to meet your needs. Read on to learn more about how LH Talent Agency can elevate your live hosting experience. More Info - https://livehosting.xyz/ -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10146] New: Typo in doc/man/man3/lber-decode.3
by openldap-its＠openldap.org 19 Dec '23

19 Dec '23

https://bugs.openldap.org/show_bug.cgi?id=10146 Issue ID: 10146 Summary: Typo in doc/man/man3/lber-decode.3 Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: joshua(a)joshua.hu Target Milestone: --- In doc/man/man3/lber-decode.3 it states that the fmt for null is: n Null. No parameter is required. The element is simply skipped if it is recognized. Should it not be 'N'? -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 7420] Possible to bypass overlay unique and constraint
by openldap-its＠openldap.org 19 Dec '23

19 Dec '23

https://bugs.openldap.org/show_bug.cgi?id=7420 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CONFIRMED |IN_PROGRESS --- Comment #7 from Howard Chu <hyc(a)openldap.org> --- Fix in https://git.openldap.org/openldap/openldap/-/merge_requests/665 please test -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10131] New: wildcard search crash slapd with OU containing parenthesis
by openldap-its＠openldap.org 12 Dec '23

12 Dec '23

https://bugs.openldap.org/show_bug.cgi?id=10131 Issue ID: 10131 Summary: wildcard search crash slapd with OU containing parenthesis Product: OpenLDAP Version: 2.5.16 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: bourguijl(a)gmail.com Target Milestone: --- Dears, When I do following ldapsearch as following : ldapsearch -x -H ldap://hostname:3891 -b "o=mobistar.be" -s subtree "(&(objectClass=groupOfUniqueNames)(uniqueMember=uid=jlb,ou=*,o=mobistar.be))" cn dn and the DB is containing these entries : dn: uid=jlb,ou=Test (aa),ou=Partners,o=mobistar.be dn: ou=Test (aa),ou=Partners,o=mobistar.be even if this "uid=jlb" isn't member of a group as uniqueMember, it makes slapd crashing. I did test it on versions 2.5.7 & 2.5.16, same result --> slapd crashed. Seems to be related to parenthesis presence in OU attribut. Is it a bug ? Thx, Jean-Luc. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9717] New: The RADIUSOV overlay can be incorporated into OpenLDAP
by openldap-its＠openldap.org 28 Nov '23

28 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9717 Issue ID: 9717 Summary: The RADIUSOV overlay can be incorporated into OpenLDAP Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: rdubner(a)symas.com Target Milestone: --- -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10132] New: manage syncrepl as a cn=config entry
by openldap-its＠openldap.org 28 Nov '23

28 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=10132 Issue ID: 10132 Summary: manage syncrepl as a cn=config entry Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Maybe it being exposed through both places (olcSyncrepl and the entry) could be a way to manage the transition (unless we have a way to handle cn=config schema upgrades internally). Uncertain as to how that affects cn=config replication. -- You are receiving this mail because: You are on the CC list for the issue.

1 1

[Issue 8826] Contrib dsaschema module needs updating for cn=config
by openldap-its＠openldap.org 28 Nov '23

28 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8826 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |IN_PROGRESS Ever confirmed|0 |1 --- Comment #1 from Ondřej Kuzník <ondra(a)mistotebe.net> --- https://git.openldap.org/openldap/openldap/-/merge_requests/661 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6166] Overlay/backend restructuring
by openldap-its＠openldap.org 23 Nov '23

23 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=6166 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=10135 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10134] New: OpenLDAP Docker Installation and Migration
by openldap-its＠openldap.org 22 Nov '23

22 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=10134 Issue ID: 10134 Summary: OpenLDAP Docker Installation and Migration Product: OpenLDAP Version: 2.5.13 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: chilimili1(a)outlook.de Target Milestone: --- Created attachment 990 --> https://bugs.openldap.org/attachment.cgi?id=990&action=edit Dockerfile.txt logs_importfile.txt logs_slaptest.txt Hi, I am currently experiencing issues while building a Docker container for OpenLDAP. I hope that an expert from the community can help me solve my problem. Issue 1: Docker Setup I'm in the process of setting up OpenLDAP within a Docker container on a RHEL 9 base OS. I've attached the Dockerfile I'm using for reference. My primary concern is that when I run the command RUN slaptest -f /tmp/slapd.conf -F /etc/openldap/slapd.d -d 1, it fails with mdb_db_open: database "dc=my-domain,dc=com": dbenv_open(/usr/var/openldap-data). mdb_db_open: database "dc=my-domain,dc=com" cannot be opened: No such file or directory (2). Restore from backup!. Interestingly, slaptest -u seems to work fine. I would greatly appreciate it if you could review my Dockerfile or provide insights into what might be causing this issue. Issue 2: LDAP Migration Additionally, I'm trying to migrate configuration data from a system using OpenLDAP 2.4.50 to OpenLDAP 2.5.13. During this process, I encountered the following error: csharp Copy code olcAuthzRegexp: value #0: keyword <olcAuthzRegexp> missing <regexp> <DN> argument slapadd: could not add entry dn="cn=config" (line=1) Dockerfile.txt logs_importfile.txt logs_slaptest.txt I'm not sure if these issues are related, but I thought it would be best to ask for your expertise on both matters. Thank you in advance for your assistance. Your guidance would be greatly appreciated. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10133] New: We tried to use centralized authentication for the root account, but it failed.
by openldap-its＠openldap.org 20 Nov '23

20 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=10133 Issue ID: 10133 Summary: We tried to use centralized authentication for the root account, but it failed. Product: OpenLDAP Version: 2.6.0 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: liubo335(a)huawei.com Target Milestone: --- When sssd+ldap is used for centralized authentication of Linux users, it is found that only non-root users can be authenticated, but the root user cannot be authenticated. Therefore, I would like to ask whether the authentication of the root user is not supported. If yes, what additional configuration items do you need to pay attention to when authenticating the root user? Looking forward to your answer, thank you very much. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 8890] adapt to 64-bit time_t on systems with 32-bit long
by openldap-its＠openldap.org 16 Nov '23

16 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8890 --- Comment #15 from tg(a)debian.org <tg(a)debian.org> --- FWIW, Debian is going to switch 32-bit ARM (with 32-bit long) to 64-bit time_t and off_t soon, and others, even m68k, will follow. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6097] MMR problems with deletes
by openldap-its＠openldap.org 16 Nov '23

16 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=6097 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.7.0 |3.0.0 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6942] updateref config is inadequate
by openldap-its＠openldap.org 16 Nov '23

16 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=6942 --- Comment #4 from Ondřej Kuzník <ondra(a)mistotebe.net> --- Maybe putting updateref on the syncrepl consumer configuration is a way to deal with this. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6198] Authorization for extensions
by openldap-its＠openldap.org 16 Nov '23

16 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=6198 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|enhancement |blocker Priority|--- |Highest -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9009] 2.7: Switch to LMDB v1.0
by openldap-its＠openldap.org 16 Nov '23

16 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9009 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |blocker -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8890] adapt to 64-bit time_t on systems with 32-bit long
by openldap-its＠openldap.org 16 Nov '23

16 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8890 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|Low |Normal -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9719] New: refreshOnly sends empty cookie when client up to date
by openldap-its＠openldap.org 16 Nov '23

16 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9719 Issue ID: 9719 Summary: refreshOnly sends empty cookie when client up to date 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: --- Syncprov will send an empty cookie if the consumer has the same cookie as provider. To the best of my knowledge this is not in line with RFC4533 and consumers would effectively drop their cookie when the search finishes. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10065] New: slapd needs a config option for the ssf of an external security proxy using "proxy protocol v2"
by openldap-its＠openldap.org 14 Nov '23

14 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=10065 Issue ID: 10065 Summary: slapd needs a config option for the ssf of an external security proxy using "proxy protocol v2" Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: sean(a)teletech.com.au Target Milestone: --- Commit 146889f introduced support for the haproxy "proxy protocol v2". A very welcome addition that allows an external security layer to be implemented. This implementation is however somewhat hobbled. Cyrus SASL uses "Security Strength Factors" or "ssf" to determine what Authentication mechanisms to offer. slapd conveys the implicit security of UNIX domain sockets to the SASL layer by specifying a non-zero ssf for these connections. This can be configured with the "olcLocalSSF" config setting. For implicit/explicit TLS connections, the "olcSecurity: tls=<n>" provides the cryptographic strength of the TLS layer to the SASL layer. For an external TLS-terminating proxy, there does not appear to be any way to inform Cyrus SASL of the presence of TLS security on these proxied connections. The outcome of this is that PLAIN and EXTERNAL authentication mechanisms are not offered to clients connecting through the secure proxy. This can be overcome by weakening the security properties of the SASL layer with the olcSaslSecProps configuration option, but this weakening will apply to all clients, not just clients connecting via the secure proxy. What is required is some way to tell slapd and it's integrated SASL layer about the presence of TLS encryption on the proxy's input. As a precaution, this might be restricted to slapd connections in the 127.0.0.0/8 [IPv6:::] address ranges. -- You are receiving this mail because: You are on the CC list for the issue.

2 29

[Issue 9902] New: Make max index DBs for back-mdb configurable
by openldap-its＠openldap.org 14 Nov '23

14 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9902 Issue ID: 9902 Summary: Make max index DBs for back-mdb configurable Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- From ITS#9895: Currently there is a hardcoded limit of 128 index DBs in back-mdb. Some sites want more than this (although there's no evidence they actually use more than 128 attributes in all of their applications' search filters). For 2.5/2.6 we can simply double the constant. For 2.7 consider making it configurable. Note that increasing the number increases the size of an LMDB transaction structure, and also increases the time needed to initialize it whenever creating a transaction, so it's a bad idea to just set this to an arbitrarily large number. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9829] New: set timeouts in remoteauth overlay
by openldap-its＠openldap.org 14 Nov '23

14 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9829 Issue ID: 9829 Summary: set timeouts in remoteauth overlay Product: OpenLDAP Version: 2.5.11 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: david.coutadeur(a)gmail.com Target Milestone: --- Currently, it seems there is no way to configure timeouts in the remoteauth overlay. For example, if I define a remoteauth_mapping with a file containing a list of hostnames, the first one is checked first. After "remoteauth_retry_count" * "connect_timeout" seconds, (210s on my system), remoteauth test the second server in the list. In some circumstances, it could be nice to set the connect timeout lower (or higher). -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9677] New: Create "make install-strip” target
by openldap-its＠openldap.org 14 Nov '23

14 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9677 Issue ID: 9677 Summary: Create "make install-strip” target Product: OpenLDAP Version: 2.5.7 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- All open source make-based projects shall follow the same naming and semantics of targets, described at https://www.gnu.org/prep/standards/html_node/Standard-Targets.html . In particular “make install-strip” shall strip the binaries during the installation, while “make install” shall not strip them. In openldap currently “make install” does strip, which surprised me. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10128] New: Unavailability of OpenSSL 3.X compatible openldap lib libldap_r.so
by openldap-its＠openldap.org 14 Nov '23

14 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=10128 Issue ID: 10128 Summary: Unavailability of OpenSSL 3.X compatible openldap lib libldap_r.so Product: OpenLDAP Version: 2.6.0 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: umakanta.senapati(a)netwitness.com Target Milestone: --- Hi Team, We are looking for openldap lib libldap_r.so compatible with openssl 3.x for el8 platform. From the release note i could check Open ldap has added openSSL 3.X support from version 2.5X onwards. But we couldn’t find any open ldap el8 rpm available with OpenSSL3.X support for 2.5.x or higher version. Please correct me if my understanding is wrong. Is there any plan to provide open ldap el8 rpm with libldap_r.so compatible with Openssl 3.X. Please help me if i can build the open ldap libldap_r.so with opensll 3.x lib or not? If yes please share the guide lines for the same. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10099] New: OpenLDAP version 2.5 & 2.6 causes IP connectivity to break and breaks basic commands like reboot
by openldap-its＠openldap.org 09 Nov '23

09 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=10099 Issue ID: 10099 Summary: OpenLDAP version 2.5 & 2.6 causes IP connectivity to break and breaks basic commands like reboot Product: OpenLDAP Version: 2.5.16 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: amcwongahey(a)rbbn.com Target Milestone: --- Created attachment 980 --> https://bugs.openldap.org/attachment.cgi?id=980&action=edit The package Makefile I am upgrading openLDAP from version 2.4.59 to 2.5.16 and am running into show stopper issues. In my environment I am running CLIENT mode only (libldap). I have tried 2.5.16 with the following combinations: openSSL version 1.1.1s and 3.0.8 Kernel versions: 5.4.92, 4.19.192 and 2.6.32 Problems described below ONLY happens when connecting with a domain controller using LDAPS - does NOT happen with LDAP (non-secure). When I use ANY combination that includes kernel version 4 or 5 along with openLDAP 2.5.16 I get random lockups to the point where IP connectivity breaks into and out of the node. And also it is so completely hosed that even issuing a reboot command from the console completely hangs and does not restart the node. The problem happens roughly 50% of the time with openLDAP combined with version 5 kernel but happens noticeably less frequently with the version 4 kernel. As soon as I kill the process that invokes the connection with openLDAP the problem clears up. I invoke the connection with the following function call: nReturnCode = ldap_sasl_bind( m_pLD, m_ADBind.GetBindDN(), LDAP_SASL_SIMPLE, &stPassword, NULL, NULL, &nMsgID); I use simple auth simply because the entire connection is secured with TLS anyway and there is another functional reason which I cannot go into details on. OpenLDAP never returns from the ldap_sasl_bind function call. It hangs somewhere inside the library but that alone cannot account for the complete lockup where basic commands like reboot, etc do not work and where all IP connectivity breaks. It seems it has to be something with openLDAP and the Linux kernel combined that triggers this issue. I am hoping that someone who is much more familiar with the libldap part of the library will pick up on this and be able to determine how to fix this. As an FYI: I also tried the very first version of 2.5.1 (alpha release) and the latest 2.6 and the problem happens on those versions as well. To be clear the problem does NOT happen if I run openLDAP 2.5.16 with Linux kernel version 2.6.32. ADDITIONALLY ALL openSSL & kernel combinations works with openLDAP version 2.4.59! I am attaching the package Makefile to this report. Below is the ldap.conf contents: TLS_REQCERT never TLS_KEY /tmp/ssl/certs/server.pem TLS_CERT /tmp/ssl/certs/server.pem TLS_PROTOCOL_MIN 3.1 sasl_secprops maxssf=0 -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 9009] 2.7: Switch to LMDB v1.0
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9009 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |db_reload -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9612] New: Change index_hash64 default to on
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9612 Issue ID: 9612 Summary: Change index_hash64 default to on Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Change the default value of index_hash64. By default this means slapd won't run on a 32-bit CPU (It will continue to work on 32-bit OSes running on 64-bit CPUs). If someone needs to run slapd on a 32-bit CPU they can turn this option off. In the documentation, mark the option as deprecated for eventual removal in a future release. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9580] New: Refresh vs. accesslog in delta-MPR
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9580 Issue ID: 9580 Summary: Refresh vs. accesslog in delta-MPR Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: replication Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- A server consuming a plain syncrepl session (might be a delta-MMR refresh) still has to log the entries into accesslog, however that accesslog stops being capable of serving as a delta-sync source: - operation entryCSNs will be out-of-order - the changes logged will not be the intended modifications (e.g. if we fell back after a conflict, the conflicting entry will be replaced with the other version, other examples available) We need to deal with that somehow, at the very least we need to make sure the consumer will not take them at face value. We could record this in the accesslog root entry if we can detect when this starts and match it up with the final cookie, syncprov would still need some tweaks to understand it. We could mark the entries received this way and make sure delta-consumers treat them as "poison", as if they were running a plain syncrepl session themselves (not update contextCSN until that's finished, mark its own accesslog entries this way, ...). Anything like that needs guarantees that it will clean itself up once all of the real plain sessions finish otherwise we've lost delta-sync altogether. A different approach might or might not be needed for live delta-persist sessions replicating from a refreshing provider, but at least that syncprov has a way of detecting this live if it chooses to. -- You are receiving this mail because: You are on the CC list for the issue.

1 13

[Issue 9341] New: Delta-sync MPR needs to be stable regardless of ordering
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9341 Issue ID: 9341 Summary: Delta-sync MPR needs to be stable regardless of ordering Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: replication Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- If two or more updates are spread across several providers before they have a chance to learn about the others, all replicas need to arrive at the same content regardless of the order in which they arrive. One example that is broken at the moment: - (csn a) server 1 accepts a modify - (csn b) server 2 accepts a delete on the same DN - (csn c) server 2 accepts an add on that DN again If a replica receives the actions in the order bca vs. abc, the content of the entry will be different even though the final CSN set is the same -> they will never converge. The ordering 'bac' also needs to result in eventual convergence, even if it means a refresh or replication from either provider stalling temporarily? Merge request with this test case (so far): https://git.openldap.org/openldap/openldap/-/merge_requests/145 -- You are receiving this mail because: You are on the CC list for the issue.

1 11

[Issue 9577] New: slapd -V should be deprecated
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9577 Issue ID: 9577 Summary: slapd -V should be deprecated Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: smckinney(a)symas.com Target Milestone: --- Sometimes a user's (present one included) ignorance gets them in trouble unnecessarily. The -V option is an example... Normally, when one wants to determine the version of a process, they use -V, or perhaps -v. With slapd, the daemon actually continues to run, which can have negative consequences. The doc clearly states that -VV is probably what the user wants, but is counter-intutive. Who RTFM's before checking the version? -V print version info (-VV exit afterwards, -VVV print info about static overlays and backends) I propose we eliminate the option to allow slapd to continue running after displaying the version. Perhaps we eliminate the -V option entirely, or just make it work the same as -VV. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9547] New: OpenLDAP does not send port as SPN when authenticating SASL GSSAPI
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9547 Issue ID: 9547 Summary: OpenLDAP does not send port as SPN when authenticating SASL GSSAPI Product: OpenLDAP Version: 2.4.44 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: robert.wilson1717(a)gmail.com Target Milestone: --- When trying to authenticate to an ADLDS server using kerberos and a MIT ccache, OpenLdap only passes the hostname to the SASL mechanism, causing a mismatch between the SPN in the client "ldap/adlds.my.domain" and the one registered in AD "ldap/adlds.my.domain:50000" Is there a way fo forcing OpenLDAP to pass the port as part of the SASL request? Or is there a part of the OpenLDAP -> Cyprus-SASL -> MIT KRB5 chain where this can be enabled? -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9506] New: dynlist: member expansion when member attribute not requested
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9506 Issue ID: 9506 Summary: dynlist: member expansion when member attribute not requested Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- When configured to do dynamic "member" expansion, i.e.: overlay dynlist dynlist-attrset groupOfURLs memberURL member Any query against an object that would trigger this expansion will incur a penalty while dynlist does the expansion work even if there was no request for the member attribute. Currently that can be worked around by specifying the manageDSAit control when doing a search on the object, but this may not be feasible for some client applications and additionally other directory servers do not do this expansion for their dynamic group implementations unless the underlying configured attribute is explicitly requested. We've already implemented this in dynlist for the memberOfAD case, we should do it here as well. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9269] New: "hidden" "subordinate" database is shown in a directory tree
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9269 Issue ID: 9269 Summary: "hidden" "subordinate" database is shown in a directory tree 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: --- "hidden" configuration option is ignored by slapd (not honored by "glue" overlay?) if the database it tries to hide is also a "subordinate" database. Checked for openldap 2.4.47 and current git master (f3952d9). -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Bug 9244] New: API calls blocking after async connect
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9244 Bug ID: 9244 Summary: API calls blocking after async connect Product: OpenLDAP Version: 2.4.49 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: ryan(a)openldap.org Target Milestone: --- Created attachment 721 --> https://bugs.openldap.org/attachment.cgi?id=721&action=edit async connect test without TLS My understanding of LDAP_OPT_CONNECT_ASYNC is that the attached program should not block. If the connection does not establish fast enough, the bind call is supposed to return LDAP_X_CONNECTING. (At least that's how I understand it, based on the original behaviour (circa 2.4.23 up to 2.4.40) as well as the bind loop in back-meta. On the other hand, the man page does "Subsequent calls to library routines will poll for completion of the connect before performing further operations" which might be interpreted as meaning they would block...) In current releases it does block, as demonstrated by strace on Linux (latency added using 'tc qdisc'): [...] connect(3, {sa_family=AF_INET, sin_port=htons(389), sin_addr=inet_addr("192.168.1.204")}, 16) = -1 EINPROGRESS (Operation now in progress) write(3, "0\f\2\1\1`\7\2\1\3\4\0\200\0", 14) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=3, events=POLLOUT|POLLERR|POLLHUP}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}]) write(3, "0\f\2\1\1`\7\2\1\3\4\0\200\0", 14) = 14 poll([{fd=3, events=POLLIN|POLLPRI}], 1, -1) = 1 ([{fd=3, revents=POLLIN}]) read(3, "0\f\2\1\1a\7\n", 8) = 8 read(3, "\1\0\4\0\4\0", 6) = 6 write(2, "OK: ldap_simple_bind_returned 0 "..., 42OK: ldap_simple_bind_returned 0 (Success) ) = 42 [...] As discussed in IRC, I believe I bisected this down to commit ae6347bac, from bug 8022. The reasoning is sound, but ldap_int_open_connection does not actually return -2, only -1 or 0. The patch is simple enough, but I'm also looking at some later commits that were probably done to work around this, and might not be needed now (bug 8957, bug 8968, bug 8980). Also need to test all setups thoroughly (ldap, ldaps, STARTTLS, not to mention back-meta/asyncmeta). I also notice that LDAP_OPT_CONNECT_ASYNC is not effective unless LDAP_OPT_NETWORK_TIMEOUT is also set. It might be intentional, but the man page doesn't mention this specifically, and I don't see why it would be necessary... -- You are receiving this mail because: You are on the CC list for the bug.

1 13

[Issue 8957] Handling of TLS in async mode
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8957 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=9244 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8968] Async connect mode does not work on Solaris
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8968 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=9244 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8980] Async mode and TLS Non-Blocking Issue
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8980 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=9244 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Bug 9229] New: Make liblutil usable by libldap
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9229 Bug ID: 9229 Summary: Make liblutil usable by libldap Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: ryan(a)openldap.org Target Milestone: --- liblutil is a static library (non-PIC) and so cannot be linked into shared objects, however we have several use cases for reusing its code in libldap. Some options: - moving more code from liblutil to libldap - just merge the whole thing? - are there components that link liblutil but _not_ libldap? - build liblutil as PIC (take a minor performance hit when linked into programs?) - build liblutil twice (liblutil.a and liblutil_pic.a) - symlink liblutil sources into libldap build dir, like libldap_r does with libldap - both of these last options require checking whether executables can call the PIC symbols safely (if some symbols are used by both library and program code) Nice-to-have for 2.5, I'd say more likely for 2.6 at this point. -- You are receiving this mail because: You are on the CC list for the bug.

1 10

[Issue 9009] 2.7: Switch to LMDB v1.0
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9009 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |9225 Referenced Issues: https://bugs.openldap.org/show_bug.cgi?id=9225 [Issue 9225] back-mdb: Add support for PREPARE/2-phase commit -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Bug 9221] New: Move all replication consumer code into its own overlay
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9221 Bug ID: 9221 Summary: Move all replication consumer code into its own overlay Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- (In relation to a discussion about slapo-chain) <hyc> anyway, the nicer ting to fix would be in 2.5, push all of the repl consumer code into its own overlay <hyc> in that case, updateref would be processed wherever the overlay was configured <hyc> so no longer tied to the frontend <hyc> it would also make it more feasible to have multiple different consumer configs in a single DB, each with their own provider URL (and thus their own updateref) <hyc> I would think we can get rid of the update ref directive entirely, just point all writes to that consumer's provider. -- You are receiving this mail because: You are on the CC list for the bug.

1 6

[Bug 9218] New: Revist entry_release handling in slapo-pache, slapo-translucent
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9218 Bug ID: 9218 Summary: Revist entry_release handling in slapo-pache, slapo-translucent Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- From a past discussion with hyc on 2.5 items: [13:57] <hyc> there's a nagging problem though, pcache's entry_release function needs to distinguish between its backend actually freeing the entry, or being a no-op [13:57] <hyc> so it can decide whether to return success or continue [13:58] <hyc> the patch to translucent sidesteps the question, by avoiding other overlays [13:58] <hyc> but we need to revisit this in 2.5 -- You are receiving this mail because: You are on the CC list for the bug.

1 8

[Bug 9217] New: Audit all schema definitions to have official non-experimental OIDs where possible
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9217 Bug ID: 9217 Summary: Audit all schema definitions to have official non-experimental OIDs where possible 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: --- From a past discussion with hyc on 2.5 requirements: [09:27] <hyc> we also need to audit all of these schema defs [09:27] <hyc> we're supposed to have official, non-experimental OIDs for released schema [09:28] <hyc> accesslog is still using 666, experimental arc [09:29] <hyc> I think this means we should polish up the logschema draft, Informational status, and publish it again as final -- You are receiving this mail because: You are on the CC list for the bug.

1 12

[Bug 9216] New: Port autoca to gnutls
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9216 Bug ID: 9216 Summary: Port autoca to gnutls Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: ryan(a)openldap.org Target Milestone: --- For 2.5, support building and running the autoca overlay with GnuTLS. -- You are receiving this mail because: You are on the CC list for the bug.

1 8

[Issue 10126] New: Openldap 2.5.16 Segmentation fault during start
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=10126 Issue ID: 10126 Summary: Openldap 2.5.16 Segmentation fault during start Product: OpenLDAP Version: 2.5.16 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: bogdan.siara(a)gmail.com Target Milestone: --- Created attachment 987 --> https://bugs.openldap.org/attachment.cgi?id=987&action=edit gdb stacktrace Hi, I have openldap cluster with 2 nodes. Openldap is compiled in docker debian:bookworm-slim with options: ./configure --prefix=${LDAP_HOME}/openldap \ --enable-debug \ --enable-dynamic \ --enable-syslog \ --enable-ipv6 \ --enable-local \ --enable-slapd \ --enable-dynacl \ --enable-cleartext \ --enable-crypt \ --enable-spasswd \ --enable-modules \ --enable-slapi \ --enable-wrappers \ --enable-dnssrv=mod \ --enable-ldap=mod \ --enable-mdb=mod \ --enable-meta=mod \ --enable-asyncmeta=mod \ --enable-relay=mod \ --enable-overlays=mod \ --enable-argon2=yes \ --enable-balancer=mod \ --with-cyrus-sasl \ --with-threads \ --with-argon2=auto \ --without-systemd \ --with-tls=openssl make depend make make install cd contrib/slapd-modules/smbk5pwd sed -i "s|prefix=/usr/local|prefix=${LDAP_HOME}/openldap|g" Makefile sed -i "s|SSL_LIB = -lcrypto|SSL_LIB = -lnettle|g" Makefile sed -i "s|HEIMDAL_INC = -I/usr/heimdal/include|HEIMDAL_INC = \$(shell krb5-config.heimdal --cflags krb5 kadm-server)|g" Makefile sed -i "s|HEIMDAL_LIB = -L/usr/heimdal/lib -lkrb5 -lkadm5srv|HEIMDAL_LIB = \$(shell krb5-config.heimdal --libs krb5 kadm-server)|g" Makefile sed -i "s|LIBS = \$(LDAP_LIB) \$(HEIMDAL_LIB) \$(SSL_LIB)|LIBS = \$(HEIMDAL_LIB) \$(LDAP_LIB) \$(SSL_LIB)|g" Makefile make make install cd ../passwd/pbkdf2 sed -i "s|prefix=/usr/local|prefix=${LDAP_HOME}/openldap|g" Makefile sed -i "s|SSL_LIB = -lcrypto|SSL_LIB = -lnettle|g" Makefile make make install cd ../sha2 sed -i "s|prefix=/usr/local|prefix=${LDAP_HOME}/openldap|g" Makefile make make install cd ../../ppm sed -i "s|prefix=/usr/local|prefix=${LDAP_HOME}/openldap|g" Makefile make make install When I start openldap: slapd -h 'ldap://0.0.0.0:10389 ldaps://0.0.0.0:10536 ldapi://%2Fopt%2Fldap%2Fldapi' -F /opt/ldap//openldap/etc/openldap/slapd.d I get error: @(#) $OpenLDAP: slapd 2.5.16 (Nov 3 2023 07:51:03) $#012#011@f3068170494c:\/opt\/ldap\/openldap-2.5.16\/servers\/slapd /opt\/ldap\/openldap\/etc\/openldap\/slapd.d: line 1: rootdn is always granted unlimited privileges. Segmentation fault (core dumped) and in syslog: Nov 6 08:48:17 openldap-1 kernel: [44480681.935173] slapd[3775972]: segfault at 7f049da0375f ip 00007f049d75fc12 sp 00007fff24e77dd0 error 7 in libcrypto.so.3[7f049d60a000+279000] Nov 6 08:48:17 openldap-1 kernel: [44480681.935183] Code: 64 f9 ff ff eb a8 e8 ed 23 eb ff 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 85 ff 0f 84 a7 00 00 00 53 b8 ff ff ff ff 48 89 fb <f0> 0f c1 47 30 83 e8 01 85 c0 74 12 7e 10 5b 31 c0 31 d2 31 f6 31 Next start with gdb: ldap@openldap-1:~$ gdb --args /opt/ldap/openldap/libexec/slapd -d 0 -h ldap://0.0.0.0:10389 -F /opt/ldap//openldap/etc/openldap/slapd.d GNU gdb (Debian 13.1-3) 13.1 Copyright (C) 2023 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /opt/ldap/openldap/libexec/slapd... (No debugging symbols found in /opt/ldap/openldap/libexec/slapd) (gdb) run Starting program: /opt/ldap/openldap/libexec/slapd -d 0 -h ldap://0.0.0.0:10389 -F /opt/ldap//openldap/etc/openldap/slapd.d [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x00007ffff79bfc12 in EVP_PKEY_free () from /lib/x86_64-linux-gnu/libcrypto.so.3 (gdb) bt full #0 0x00007ffff79bfc12 in EVP_PKEY_free () from /lib/x86_64-linux-gnu/libcrypto.so.3 No symbol table info available. #1 0x00007ffff79fa393 in ?? () from /lib/x86_64-linux-gnu/libcrypto.so.3 No symbol table info available. #2 0x00007ffff79fa8cd in PEM_read_bio_Parameters_ex () from /lib/x86_64-linux-gnu/libcrypto.so.3 No symbol table info available. #3 0x00007ffff7fa1b38 in tlso_ctx_init (lo=0x5555556fd550, lt=0x7fffffffe280, is_server=1) at tls_o.c:546 dh = 0x7ffff7c6372f <SSL_CTX_new_ex+815> bio = 0x5555558afab0 ctx = 0x55555586b760 i = <optimized out> #4 0x00007ffff7f9de08 in ldap_int_tls_init_ctx (lo=0x5555556fd550, is_server=1) at tls2.c:264 rc = 0 ti = <optimized out> lts = {lt_certfile = 0x555555773350 "/opt/ldap/openldap/etc/openldap/certs/ldap.crt", lt_keyfile = 0x555555773390 "/opt/ldap/openldap/etc/openldap/certs/ldap.key", lt_dhfile = 0x555555773470 "/opt/ldap/openldap/etc/openldap/certs/dhparam", lt_cacertfile = 0x555555773310 "/opt/ldap/openldap/etc/openldap/certs/ca.crt", lt_cacertdir = 0x0, lt_ciphersuite = 0x5555557733d0 "TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-256-GCM-SHA384:TLS13-AES-128-GCM-SHA256:EECDH+CHACHA20:EECDH+AESGCM:EDH+AESGCM", lt_crlfile = 0x0, lt_randfile = 0x0, lt_ecname = 0x0, lt_protocol_min = 771, lt_protocol_max = 0, lt_cacert = {bv_len = 0, bv_val = 0x0}, lt_cert = {bv_len = 0, bv_val = 0x0}, lt_key = { bv_len = 0, bv_val = 0x0}} #5 0x00005555555759e7 in main () No symbol table info available. (gdb) thread apply all bt Thread 1 (Thread 0x7ffff75ce7c0 (LWP 64) "slapd"): #0 0x00007ffff79bfc12 in EVP_PKEY_free () from /lib/x86_64-linux-gnu/libcrypto.so.3 #1 0x00007ffff79fa393 in ?? () from /lib/x86_64-linux-gnu/libcrypto.so.3 #2 0x00007ffff79fa8cd in PEM_read_bio_Parameters_ex () from /lib/x86_64-linux-gnu/libcrypto.so.3 #3 0x00007ffff7fa1b38 in tlso_ctx_init (lo=0x5555556fd550, lt=0x7fffffffe280, is_server=1) at tls_o.c:546 #4 0x00007ffff7f9de08 in ldap_int_tls_init_ctx (lo=0x5555556fd550, is_server=1) at tls2.c:264 #5 0x00005555555759e7 in main () Next I rebuild openldap adding flags to configure step: ./configure CFLAGS=-g When I run slapd in new image: slapd -h 'ldap://0.0.0.0:10389 ldaps://0.0.0.0:10536 ldapi://%2Fopt%2Fldap%2Fldapi' -F /opt/ldap//openldap/etc/openldap/slapd.d all working well and I didn't get segementation fault. Can someone tell me what I'm doing wrong and how to investigate the problem? Regards BS -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10127] New: Thread Safety in LMDB with MDB_NOTLS and Readonly Cursors
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=10127 Issue ID: 10127 Summary: Thread Safety in LMDB with MDB_NOTLS and Readonly Cursors Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: xiaoya2wei(a)gmail.com Target Milestone: --- Greetings LMDB Community, I am delving into the thread-safety aspects of LMDB, specifically regarding the use of readonly cursors across multiple threads. With the MDB_NOTLS flag enabled, which disables thread-local storage, my understanding is that readonly transactions may be shared between threads, provided there is proper synchronization to prevent concurrent access. Building upon this, I seek clarity on the following: Can multiple threads safely access a single readonly cursor derived from such a synchronized readonly transaction when MDB_NOTLS is enabled? Upon reviewing the LMDB source code, I noticed that cursors are tied to transactions (see mdb.c#L1335). This suggests that if threads can synchronously share a transaction, they might also share a cursor associated with it for data retrieval. I recognize my analysis might be superficial, and I'm open to corrections. Your insights on this matter would be greatly appreciated to enhance my understanding of LMDB's concurrency mechanisms. Thank you in advance for your assistance! -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 8852] slapd memory use grows continuously with non-delta syncrepl and modifying groups
by openldap-its＠openldap.org 03 Nov '23

03 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8852 --- Comment #8 from Ondřej Kuzník <ondra(a)mistotebe.net> --- For comparison, using deltasync (and sortvals!) makes the consumer take a similar amount of CPU time (about +50-90 % on the provider's) to process the 10k value additions, just like Ryan noted earlier. On the other idea, no clue on whether we can somehow limit the amount of data queued up without severely impairing replication progress. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8852] slapd memory use grows continuously with non-delta syncrepl and modifying groups
by openldap-its＠openldap.org 03 Nov '23

03 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8852 --- Comment #7 from Ondřej Kuzník <ondra(a)mistotebe.net> --- Making attr_cmp do a linear sweep for sortvals attributes (instead of the quadratic match it has to do right now) makes the consumer 7-8x slower than a provider across the board with the environment provided. I might have expected something like 3-4x but that's out of scope for this particular ITS. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8180] back-sock should not return sucess in case of error
by openldap-its＠openldap.org 02 Nov '23

02 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8180 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |IN_PROGRESS Ever confirmed|0 |1 --- Comment #2 from Howard Chu <hyc(a)openldap.org> --- https://git.openldap.org/openldap/openldap/-/merge_requests/657 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8677] back-sock segfaults on CONTINUE (database sock)
by openldap-its＠openldap.org 02 Nov '23

02 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8677 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |IN_PROGRESS Ever confirmed|0 |1 --- Comment #3 from Howard Chu <hyc(a)openldap.org> --- https://git.openldap.org/openldap/openldap/-/merge_requests/657 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6198] Authorization for extensions
by openldap-its＠openldap.org 02 Nov '23

02 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=6198 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |9204 Referenced Issues: https://bugs.openldap.org/show_bug.cgi?id=9204 [Issue 9204] slapo-constraint allows anyone to apply Relax control -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8884] enabling overlay slapo-rwm makes 'entryDN' invisible
by openldap-its＠openldap.org 02 Nov '23

02 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8884 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs(a)openldap.org |hyc(a)openldap.org -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8498] slapadd complains about missing attrs
by openldap-its＠openldap.org 02 Nov '23

02 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8498 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |TEST Status|UNCONFIRMED |RESOLVED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8852] slapd memory use grows continuously with non-delta syncrepl and modifying groups
by openldap-its＠openldap.org 02 Nov '23

02 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8852 --- Comment #6 from Ondřej Kuzník <ondra(a)mistotebe.net> --- attr_cmp should check the attribute is a sortval and if so, should diff without resolving to a double loop. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8498] slapadd complains about missing attrs
by openldap-its＠openldap.org 02 Nov '23

02 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8498 --- Comment #5 from Howard Chu <hyc(a)openldap.org> --- Fixed in master 2939df1a1dead2a11d1878ccd246660cda2b41a6 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8852] slapd memory use grows continuously with non-delta syncrepl and modifying groups
by openldap-its＠openldap.org 02 Nov '23

02 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8852 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs(a)openldap.org |ondra(a)mistotebe.net --- Comment #5 from Quanah Gibson-Mount <quanah(a)openldap.org> --- May be possible to improve diff code for standard syncrepl to improve performance on the consumer side if the attribute is sorted via sortvals, needs investigation. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8852] slapd memory use grows continuously with non-delta syncrepl and modifying groups
by openldap-its＠openldap.org 02 Nov '23

02 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8852 --- Comment #4 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Similarly, when I used AWS, it was necessary to have the consumers be set at 4k IOPS while the providers were 3k IOPS. I.e., it's generally necessary that consumers be faster than providers when processing large sequences of write updates. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8826] Contrib dsaschema module needs updating for cn=config
by openldap-its＠openldap.org 02 Nov '23

02 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8826 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs(a)openldap.org |ondra(a)mistotebe.net -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8678] Slow deletes of large indexed attrributes
by openldap-its＠openldap.org 02 Nov '23

02 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8678 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs(a)openldap.org |hyc(a)openldap.org -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8677] back-sock segfaults on CONTINUE (database sock)
by openldap-its＠openldap.org 02 Nov '23

02 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8677 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|overlays |backends -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8581] slapd-meta backend SSL negotiation timeout
by openldap-its＠openldap.org 02 Nov '23

02 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8581 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8581] slapd-meta backend SSL negotiation timeout
by openldap-its＠openldap.org 02 Nov '23

02 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8581 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #5 from Quanah Gibson-Mount <quanah(a)openldap.org> --- *** This issue has been marked as a duplicate of issue 8047 *** -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8047] TIMEOUT and NETWORK_TIMEOUT don't work properly with SSL
by openldap-its＠openldap.org 02 Nov '23

02 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8047 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |louis.chanouha@univ-toulous | |e.fr --- Comment #10 from Quanah Gibson-Mount <quanah(a)openldap.org> --- *** Issue 8581 has been marked as a duplicate of this issue. *** -- You are receiving this mail because: You are on the CC list for the issue.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs