openldap-bugs October 2023

openldap-bugs@openldap.org

2 participants
155 discussions

[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 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 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 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 9920] New: MDB_PAGE_FULL with master3 (encryption) because there is no room for the authentication data (MAC)
by openldap-its＠openldap.org 24 Dec '23

24 Dec '23

https://bugs.openldap.org/show_bug.cgi?id=9920 Issue ID: 9920 Summary: MDB_PAGE_FULL with master3 (encryption) because there is no room for the authentication data (MAC) Product: LMDB Version: unspecified Hardware: x86_64 OS: Mac OS Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: info(a)parlepeuple.fr Target Milestone: --- Created attachment 915 --> https://bugs.openldap.org/attachment.cgi?id=915&action=edit proposed patch Hello, on master3, using the encryption at rest feature, I am testing as follow: - on a new named database, i set the encryption function with mdb_env_set_encrypt(env, encfunc, &enckey, 32) - note that I chose to have a size parameter (The size of authentication data in bytes, if any. Set this to zero for unauthenticated encryption mechanisms.) of 32 bytes. - I add 2 entries on the DB, trying to saturate the first page. I chose to add a key of 33 Bytes and a value of 1977 Bytes, so the size of each node is 2010 Bytes (obviously the 2 keys are different). - This passes and the DB has just one leaf_pages, no overflow_pages, no branch_pages, an a depth of 1. - If I add one byte to the values I insert (starting again from a blank DB), then , instead of seeing 2 overflow_pages, I get an error : MDB_PAGE_FULL. - this clearly should not have happened. - Here is some tracing : add to leaf page 2 index 0, data size 48 key size 7 [74657374646200] add to leaf page 3 index 0, data size 1978 key size 33 [000000000000000000000000000000000000000000000000000000000000000000] add to branch page 5 index 0, data size 0 key size 0 [null] add to branch page 5 index 1, data size 0 key size 33 [000000000000000000000000000000000000000000000000000000000000000000] add to leaf page 4 index 0, data size 1978 key size 33 [000000000000000000000000000000000000000000000000000000000000000000] add to leaf page 4 index 1, data size 1978 key size 33 [020202020202020202020202020202020202020202020202020202020202020202] not enough room in page 4, got 1 ptrs upper-lower = 2020 - 2 = 2016 node size = 2020 Looking at the code, I understand that there is a problem at line 9005 : } else if (node_size + data->mv_size > mc->mc_txn->mt_env->me_nodemax) { where me_nodemax is incorrect, as it is not taking into account that some bytes will be needed for the MAC authentication code, which size is in env->me_esumsize. me_nodemax is calculated at line 5349: env->me_nodemax = (((env->me_psize - PAGEHDRSZ ) / MDB_MINKEYS) & -2) - sizeof(indx_t); So I substract me_esumsize with a "- env->me_esumsize" here: env->me_nodemax = (((env->me_psize - PAGEHDRSZ - env->me_esumsize) / MDB_MINKEYS) & -2) - sizeof(indx_t); I also substract it from me_maxfree_1pg in the line above, and in pmax in line 10435. I do not know if my patch is correct, but it solves the issue. Maybe there are other places in the code where the me_esumsize should be substracted from the available size. By example, when calculating the number of overflow pages in OVPAGES, it does not take into account me_esumsize, but I think it is ok, because there is only one MAC for the entire set of OV pages, and there is room for it in the first OV page. See the attached proposed patch. -- You are receiving this mail because: You are on the CC list for the issue.

1 8

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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs October 2023