openldap-bugs April 2024

openldap-bugs@openldap.org

1 participants
40 discussions

[Issue 10155] New: Invalid [aka FUZZ] -F and -T options can core dump ldapsearch
by openldap-its＠openldap.org 16 Apr '24

16 Apr '24

https://bugs.openldap.org/show_bug.cgi?id=10155 Issue ID: 10155 Summary: Invalid [aka FUZZ] -F and -T options can core dump ldapsearch Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: doug.leavitt(a)oracle.com Target Milestone: --- A customer reported core dumps in ldapsearch which has been tracked to the the improper use of the -F and -T options. The customer confirmed removing the invalid -F and -T options from their script eliminated the core dumps. The CLI arguments of the failing ldapsearch look like: ldapsearch <good CLI args> -F , -T u <good filter and attr args> The good CLI args include proper uses of -H... -x -D ... -w ... -b ... -s ... The good filter and attrs are also valid CLI inputs. The "bad" args are <sp>-F<sp><COMMA><sp>-T<sp>-u<sp> The -u is also valid but it is consumed as a directory name of -T From man page and code review the the -F argument is supposed to be a valid URL. and the -T argument is supposed to be a valid directory The core file output indicates that main calls free after the search takes place. The location is believed to be here: 1658 if ( urlpre != NULL ) { 1659 if ( def_urlpre != urlpre ) 1660 free( def_urlpre ); <--------- 1661 free( urlpre ); 1662 } ... 1672 tool_exit( ld, rc ); ... This is the first example of the use of -F we have seen so it is unclear how this should be fixed. But code review of ldapsearch.c and common.c exposed a few weaknesses that could help in addressing the issue. Observed weaknesses: The getopt processing code for -T does not check that the arg is actually a directory and fail/error when bad input is provided. Perhaps at least an access(2) check should be performed? It is unclear if -F should only accept file:// URLs. The existing code does not sufficiently check any URL format instead it processes the argument by looking for the first '/' [no error checking] and determine the remainder to be a tmpdir location similar to the -T argument. So, Fuzz input of <COMMA> seems to eventually lead to the core files. It is unclear if -F and -T should be mutually exclusive or not. It seems like the fix to this issue is to add better error checking and to fail on FUZZ inputs. I defer a solution to upstream as it probably requires project direction I lack. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9934] New: slapd-config(5) should document how to store certificates for slapd usage
by openldap-its＠openldap.org 16 Apr '24

16 Apr '24

https://bugs.openldap.org/show_bug.cgi?id=9934 Issue ID: 9934 Summary: slapd-config(5) should document how to store certificates for slapd usage Product: OpenLDAP Version: 2.5.13 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Commit 7b41feed83b expanded the ability of cn=config to save the certificates used for TLS by slapd directly in the config database. However the documentation for the new parameters was never added to the slapd-config(5) man page. olcTLSCACertificate $ olcTLSCertificate $ olcTLSCertificateKey -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10020] New: dynlist's @groupOfUniqueNames is considered only for the first configuration line
by openldap-its＠openldap.org 16 Apr '24

16 Apr '24

https://bugs.openldap.org/show_bug.cgi?id=10020 Issue ID: 10020 Summary: dynlist's @groupOfUniqueNames is considered only for the first configuration line Product: OpenLDAP Version: 2.5.13 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: msl(a)touk.pl Target Milestone: --- If we consider the following configuration of dynlist: {0}toukPerson labeledURI uniqueMember+memberOf@groupOfUniqueNames {1}groupOfURLs memberURL uniqueMember+dgMemberOf@groupOfUniqueNames The {0} entry will correctly populate the memberOf relatively to static group membership. The {1} entry will produce dgMemberOf with dynamic group membership correctly (based on memberURL query) but it will not populate static entries IF {0} entry in configuration is present. IF I remove {0} from the dynlist configuration - or - remove @groupOfUniqueNames part from this configuration line, then both dynamic and static entries will be populated correctly for {1}. So the effects are as follows on some user entry: if both {0} and {1} are present - {1} produced only dynamic groups: memberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl memberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl dgMemberOf: cn=dyntouk,ou=dyntest,ou=group,dc=touk,dc=pl if both {0} and {1} are present and @groupOfUniqueNames is removed from {0} - {1} produced static+dynamic groups: dgMemberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl dgMemberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl dgMemberOf: cn=dyntouk,ou=dyntest,ou=group,dc=touk,dc=pl If only {1} is present - {1} produced static+dynamic groups: dgMemberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl dgMemberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl dgMemberOf: cn=dyntouk,ou=dyntest,ou=group,dc=touk,dc=pl For completness - if only {0} is present: memberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl memberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl I would expect this behavior to be correct for the first case - {0} and {1}. memberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl memberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl dgMemberOf: cn=dyntouk,ou=dyntest,ou=group,dc=touk,dc=pl dgMemberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl dgMemberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10026] New: Refresh handling can skip entries (si_dirty not managed properly)
by openldap-its＠openldap.org 16 Apr '24

16 Apr '24

https://bugs.openldap.org/show_bug.cgi?id=10026 Issue ID: 10026 Summary: Refresh handling can skip entries (si_dirty not managed properly) 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: --- Take MPR plain syncrepl with 3+ providers. When a provider's own syncrepl session transitions to persist and a it starts a new parallel session towards another host, that session always has to start as a refresh. If that refresh serves entries to us, our handling of si_dirty is not consistent: - if the existing persist session serves some of these entries to us, we can "forget" to pass the others to a newly connected consumer - same if the refresh is abandoned and we start refreshing from a different provider that might be behind what we were being served (again our consumers could suffer) - if we restart, si_dirty is forgotten and our consumers suffer even worse We might need to be told (at the beginning of the refresh?) what the end state we're going for is, so we can keep si_dirty on until then. And somehow persist that knowledge in the DB... -- You are receiving this mail because: You are on the CC list for the issue.

1 7

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

16 Apr '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 3

[Issue 10168] New: olcdbindex doesn't cleanup cleanly
by openldap-its＠openldap.org 16 Apr '24

16 Apr '24

https://bugs.openldap.org/show_bug.cgi?id=10168 Issue ID: 10168 Summary: olcdbindex doesn't cleanup cleanly 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: --- if you run the following modify against slapd (notice the olcDbMultival data is wrong), slapd aborts in mdb_cf_cleanup->mdb_attr_dbs_open when cleaning up the olcDbIndex changes: dn: olcDatabase={1}mdb,cn=config changetype: modify add: olcDbIndex olcDbIndex: member eq olcDbIndex: memberof eq - add: olcDbMultival olcDbMultival: member,memberOf 5,15 - -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10191] New: backend searches should respond to pause requests
by openldap-its＠openldap.org 16 Apr '24

16 Apr '24

https://bugs.openldap.org/show_bug.cgi?id=10191 Issue ID: 10191 Summary: backend searches should respond to pause requests Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- A long running search will cause mods to cn=config to wait a long time. Search ops should periodically check for threadpool pause requests. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10162] New: Fix for binary attributes data corruption in back-sql
by openldap-its＠openldap.org 16 Apr '24

16 Apr '24

https://bugs.openldap.org/show_bug.cgi?id=10162 Issue ID: 10162 Summary: Fix for binary attributes data corruption in back-sql Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: dex.tracers(a)gmail.com Target Milestone: --- Created attachment 1006 --> https://bugs.openldap.org/attachment.cgi?id=1006&action=edit Fix for binary attributes corruption on backed-sql I've configured slapd to use back-sql (mariadb through odbc) and observed issues with the BINARY data retrievals from the database. The length of the attributes was properly reported, but the correct data inside was always 16384 bytes and after that point - some junk (usually filled-up with AAAAAAAA and some other attributes data from memory). During the debugging - I've noticed that: - The MAX_ATTR_LEN (16384 bytes) is used to set the length of the data for BINARY columns when SQLBindCol is done inside of the "backsql_BindRowAsStrings_x" function - After SQLFetch is done - data in row->cols[i] is fetched up to the specified MAX_ATTR_LEN - After SQLFetch is done - the correct data size (greater than MAX_ATTR_LEN) is represented inside of the row->value_len I'm assuming that slapd allocates the pointer in memory (row->cols[i]), fills it with the specified amount of data (MAX_ATTR_LEN), but when forming the actual attribute data - uses the length from row->value_len and so everything from 16384 bytes position till row->value_len is just a junk from the memory (uninitialized, leftovers, data from other variables). After an investigation, I've find-out that: - for BINARY or variable length fields - SQLGetData should be used - SQLGetData supports chunked mode (if length is unknown) or full-read mode if the length is known - it could be used in pair with SQLBindCol after SQLFetch (!) Since we have the correct data length inside of row->value_len, I've just added the code to the backsql_get_attr_vals() function to overwrite the corrupted data with the correct data by issuing SQLGetData request. And it worked - binary data was properly retrieved and reported over LDAP! My current concerns / help needed - I'm not very familiar with the memory allocation/deallocation mechanisms, so I'm afraid that mentioned change can lead to memory corruption (so far not observed). Please review attached patch (testing was done on OPENLDAP_REL_ENG_2_5_13, and applied on the master branch for easier review/application). -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 7249] slapd segfault with memberof overlay on frontend db
by openldap-its＠openldap.org 16 Apr '24

16 Apr '24

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

1 0

[Issue 10202] New: slapd fails to start if compiled with --enable-overlays=yes
by openldap-its＠openldap.org 16 Apr '24

16 Apr '24

https://bugs.openldap.org/show_bug.cgi?id=10202 Issue ID: 10202 Summary: slapd fails to start if compiled with --enable-overlays=yes Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- Statically compiling all overlays produces the following error at slapd startup: 66192034.2adbbeb4 0x73de9d4547c0 register_at: AttributeType "( 1.2.840.113556.1.2.102 NAME 'memberOf' DESC 'Group that the entry belongs to' SYNTAX '1.3.6.1.4.1.1466.115.121.1.12' EQUALITY distinguishedNameMatch USAGE dSAOperation NO-USER-MODIFICATION X-ORIGIN 'iPlanet Delegated Administrator' )": Duplicate attributeType, 1.2.840.113556.1.2.102 66192034.2adc2a97 0x73de9d4547c0 overlay_register("nestgroup"): name already in use. 66192034.2adc44ed 0x73de9d4547c0 nestgroup overlay setup failed, err -1 66192034.2adc5016 0x73de9d4547c0 slapd: overlay_init failed 66192034.2adc5e14 0x73de9d4547c0 slapd destroy: freeing system resources. 66192034.2adefbff 0x73de9d4547c0 slapd stopped. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs April 2024