openldap-bugs October 2024

openldap-bugs@openldap.org

1 participants
124 discussions

[Issue 10227] New: Asyncmeta will not reset a connection if a bind operation fails with LDAP_OTHER, leaving the connection in invalid state
by openldap-its＠openldap.org 26 Nov '24

26 Nov '24

https://bugs.openldap.org/show_bug.cgi?id=10227 Issue ID: 10227 Summary: Asyncmeta will not reset a connection if a bind operation fails with LDAP_OTHER, leaving the connection in invalid state Product: OpenLDAP Version: 2.6.8 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: --- The issue is difficult to reproduce, it can happen under heavy traffic if the target is configured to do a sasl bind with a custom saslmech. In any case, currently asyncmeta only resets the connection of the error is LDAP_UNAVAILABLE, which is incorrect. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10219] New: Modify of olcDisabled by removing and adding a value invokes db_open twice
by openldap-its＠openldap.org 26 Nov '24

26 Nov '24

https://bugs.openldap.org/show_bug.cgi?id=10219 Issue ID: 10219 Summary: Modify of olcDisabled by removing and adding a value invokes db_open twice Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- A database is enabled by default, and therefore a missing olcDisabled attribute is equivalent to a value of FALSE. This means that currently a modify operation that removes a olcDisabled value will invoke the db_open handler for that database, even if in the same modify operation a value of TRUE is added. A modify operation like this: dn: olcDatabase={1}asyncmeta,cn=config changetype: modify delete: olcDisabled olcDisabled: FALSE - add: olcDisabled olcDisabled: TRUE - will call both db_open and db_close. This could be potentially harmful if the backend type allocates memory on db_open like asyncmeta, for example. It is a rare case, but it is best to fix it just in case. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10224] New: tlso_session_pinning: return codes from EVP* calls are not checked; can result in crashes or undefined behavior in library
by openldap-its＠openldap.org 26 Nov '24

26 Nov '24

https://bugs.openldap.org/show_bug.cgi?id=10224 Issue ID: 10224 Summary: tlso_session_pinning: return codes from EVP* calls are not checked; can result in crashes or undefined behavior in library Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: yaneurabeya(a)gmail.com Target Milestone: --- EVP* calls made in tlso_session_pinning on lines 1189-1191 [1] are not checked when computing the digest which is eventually placed in `keyhash.bv_val` on line [2]. Not checking the EVP* calls can result in undefined behavior, e.g., a library crash with SIGBUS, SIGSEGV, etc, and/or incorrect results when analyzing `keyhash.bv_val` later. The calls should be checked to avoid this scenario. Reported by Coverity. 1. https://github.com/openldap/openldap/blob/15edb3b30f2b6a3dbdf77cc42d39466d5… 2. https://github.com/openldap/openldap/blob/15edb3b30f2b6a3dbdf77cc42d39466d5… -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10280] New: Combining positive & negated filters doesn't work with dynlist
by openldap-its＠openldap.org 26 Nov '24

26 Nov '24

https://bugs.openldap.org/show_bug.cgi?id=10280 Issue ID: 10280 Summary: Combining positive & negated filters doesn't work with dynlist Product: OpenLDAP Version: 2.5.18 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: code(a)pipoprods.org Target Milestone: --- The directory contains 3 users & 2 groups. user1 is in group1, user2 is in group2, user3 isn't is any group. Filter [1] matches users that are either: - member of group1 - member of group2 ✅ It returns user1 & user2 Filter [2] matches user that are: - not member of group1 nor group2 ✅ It returns user3 Filter [3] should match users that are either: - member of group1 - member of group2 - not member of group1 nor group2 ❌ It should return the 3 users but only returns users matched by the first part of the filter (whatever the first part, if we swap both parts we get the complementary search results) Filter [1]: (|(memberOf=cn=group1,ou=example-groups,dc=example,dc=com)(memberOf=cn=group2,ou=example-groups,dc=example,dc=com)) Filter [2]: (!(|(memberOf=cn=group1,ou=example-groups,dc=example,dc=com)(memberOf=cn=group2,ou=example-groups,dc=example,dc=com))) Filter [3]: (|(memberOf=cn=group1,ou=example-groups,dc=example,dc=com)(memberOf=cn=group2,ou=example-groups,dc=example,dc=com)(!(|(memberOf=cn=group1,ou=example-groups,dc=example,dc=com)(memberOf=cn=group2,ou=example-groups,dc=example,dc=com)))) Here's my dynlist config: ``` dn: olcOverlay={2}dynlist,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcDynListConfig olcOverlay: {2}dynlist olcDynListAttrSet: {0}groupOfURLs memberURL member+memberOf@groupOfNames structuralObjectClass: olcDynListConfig entryUUID: 7df8328a-fd72-103e-82df-6fed25d5f6c8 creatorsName: cn=config createTimestamp: 20240902122741Z entryCSN: 20240902122741.257759Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20240902122741Z ``` Here's a LDIF to initialise directory contents: ``` dn: ou=example-groups,dc=example,dc=com changetype: add objectClass: organizationalUnit ou: example-groups dn: ou=example-users,dc=example,dc=com changetype: add objectClass: organizationalUnit ou: example-users dn: uid=user1,ou=example-users,dc=example,dc=com changetype: add objectClass: inetOrgPerson cn: User sn: One uid: user1 dn: uid=user2,ou=example-users,dc=example,dc=com changetype: add objectClass: inetOrgPerson cn: User sn: Two uid: user2 dn: uid=user3,ou=example-users,dc=example,dc=com changetype: add objectClass: inetOrgPerson cn: User sn: Three uid: user3 dn: cn=group1,ou=example-groups,dc=example,dc=com changetype: add objectClass: groupOfNames cn: group1 member: uid=user1,ou=example-users,dc=example,dc=com dn: cn=group2,ou=example-groups,dc=example,dc=com changetype: add objectClass: groupOfNames cn: group2 member: uid=user2,ou=example-users,dc=example,dc=com ``` -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10135] New: dynlist (and maybe others) doesn't use the right overinst context in callbacks
by openldap-its＠openldap.org 26 Nov '24

26 Nov '24

https://bugs.openldap.org/show_bug.cgi?id=10135 Issue ID: 10135 Summary: dynlist (and maybe others) doesn't use the right overinst context in callbacks 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: --- Running the test suite with `-fsanitize=address` picks up a bug in https://git.openldap.org/openldap/openldap/-/blob/860b61f41dfeeb19cc0eb011f… Here, op->o_bd->bd_info isn't actually dynlist but mdb's own static bi, so overlay_entry_get_ov then reaches into the void when reading on->on_info. It's very likely that other places/overlays share the same bug as it is subtle and doesn't get picked up immediately (slap_overinst embeds a BackendInfo and oi_orig is not often set). -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 10071] New: Extra sids in cookie should only be ignored for replay consideration
by openldap-its＠openldap.org 26 Nov '24

26 Nov '24

https://bugs.openldap.org/show_bug.cgi?id=10071 Issue ID: 10071 Summary: Extra sids in cookie should only be ignored for replay consideration 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: --- A consumer's cookie might contain sids that the provider is not aware of. Those are currently screened out. This is appropriate for initial checks whether/how to allow the operation to go ahead but might be needed for content determination in refresh/persist. As such the cookie should be retained rather than edited in place. I don't have the logs from a failed test at hand but will post the analysis/logs if I find them again. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10271] New: EINTR is handled as LDAP_SERVER_DOWN in socket operation in ldap client APIs
by openldap-its＠openldap.org 26 Nov '24

26 Nov '24

https://bugs.openldap.org/show_bug.cgi?id=10271 Issue ID: 10271 Summary: EINTR is handled as LDAP_SERVER_DOWN in socket operation in ldap client APIs Product: OpenLDAP Version: 2.5.18 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: volan.shu(a)nokia.com Target Milestone: --- In case EINTR fired by OS in any case in ldap client api for socket related operation, the ldap client API returns LDAP_SERVER_DOWN which is not correct. In this case, I suppose the ldap client need retry socket operateion. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10106] New: Add organization to web list of OpenLDAP support providers
by openldap-its＠openldap.org 12 Nov '24

12 Nov '24

https://bugs.openldap.org/show_bug.cgi?id=10106 Issue ID: 10106 Summary: Add organization to web list of OpenLDAP support providers Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: sudo(a)migrateq.io Target Milestone: --- Hello! This request is being opened as suggested by Quanah Gibson-Mount. Could you please add Migrateq to your OpenLDAP Support page on https://openldap.org/support Company: Migrateq Inc. Website: https://migrateq.io/support/tech/openldap Migrateq provides migrations, integrations and advanced 24/7/365 technical support for OpenLDAP and most Linux and Open Source Software. Thank you =) Richard -- You are receiving this mail because: You are on the CC list for the issue.

1 11

[Issue 10141] New: 100% CPU consumption with ldap_int_tls_connect
by openldap-its＠openldap.org 12 Nov '24

12 Nov '24

https://bugs.openldap.org/show_bug.cgi?id=10141 Issue ID: 10141 Summary: 100% CPU consumption with ldap_int_tls_connect Product: OpenLDAP Version: 2.6.3 Hardware: Other OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: vivekanand754(a)gmail.com Target Milestone: --- While doing secure ldap connection, i'm seeing that connection is getting stuck in read block in case it is unable to connect active directory sometime: ~ # strace -p 15049 strace: Process 15049 attached read(3, 0x55ef720bda53, 5) = -1 EAGAIN (Resource temporarily unavailable) read(3, 0x55ef720bda53, 5) = -1 EAGAIN (Resource temporarily unavailable) .. .. .. .. After putting some logs, I can see that "ldap_int_tls_start" function of "openldap-2.6.3/libraries/libldap/tls2.c" calls "ldap_int_tls_connect" in while loop. It seems to be blocking call, as it try to connect continuously until it get connected(ti_session_connect returns 0) and thus consumes 100% CPU during that time. Is there any known issue ? -- You are receiving this mail because: You are on the CC list for the issue.

1 17

[Issue 9393] New: Provider a LDAP filter validation function
by openldap-its＠openldap.org 12 Nov '24

12 Nov '24

https://bugs.openldap.org/show_bug.cgi?id=9393 Issue ID: 9393 Summary: Provider a LDAP filter validation function Product: OpenLDAP Version: 2.4.56 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: best(a)univention.de Target Milestone: --- In many situations I need to validate if a user submitted LDAP filter has valid syntax. It seems there is no official function to check this. Could you provide one? libraries/libldap/filter.c: ldap_pvt_put_filter() can be used as a basis. -- My current workaround is using a unconnected ldap connection and do a search with that filter. This yields a FILTER_ERROR (invalid filter) or a SERVER_DOWN error (invalid filter). See also: https://github.com/python-ldap/python-ldap/pull/272 -- You are receiving this mail because: You are on the CC list for the issue.

1 12

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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs October 2024