- openldap-bugs - openldap.org

[Issue 10476] slapo-pcache crashes on cached bind attributes containing LDAP filter metachars
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

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

1 0

[Issue 10489] New: memory issue in liblber
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10489 Issue ID: 10489 Summary: memory issue in liblber Product: OpenLDAP Version: 2.6.9 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: yutengsun1997(a)gmail.com Target Milestone: --- Dear OpenLDAP Security Team, I reported a potential security issue two weeks ago, but have not received a response. I am writing to confirm whether I emailed the right place. I can attach the email content if required. Looking forward to your reply. Many thanks. Regards, Yt -- You are receiving this mail because: You are on the CC list for the issue.

1 18

[Issue 10496] New: Remove references to Mozilla NSS in lload.conf(5) man page
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10496 Issue ID: 10496 Summary: Remove references to Mozilla NSS in lload.conf(5) man page Product: OpenLDAP Version: 2.6.10 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: --- We removed Mozilla NSS support in OpenLDAP 2.5, remove references to it from OpenLDAP 2.6 man pages. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10495] New: Environment variable for Systemd is ignored by configure
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10495 Issue ID: 10495 Summary: Environment variable for Systemd is ignored by configure Product: OpenLDAP Version: 2.6.13 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: openldap.aftermost863(a)passinbox.com Target Milestone: --- Hello, When using the configure script to generate the Makefile, the documentation in the --help option states that the environment variable 'systemdsystemunitdir' can be used to override the default system path for Systemd units. However, this does not work: if I export the variable with a valid existing path (e.g. 'export systemdsystemunitdir=/tmp/test') and then run ./configure, the variable is found but is ignored in the output variables and is therefore not used in the Makefile. config.log: ... ## ---------------- ## ## Cache variables. ## ## ---------------- ## ... ac_cv_env_systemdsystemunitdir_set=set ac_cv_env_systemdsystemunitdir_value=/tmp/test ... ## ----------------- ## ## Output variables. ## ## ----------------- ## ... systemdsystemunitdir='/usr/lib/systemd/system' ... The configure script seems to override that variable on line 23942: systemdsystemunitdir= I don’t quite understand why this line is there, and it seems suspicious to me. However, if I remove it and run ./configure again in the exact same shell, config.log now shows the correct path in the output variables, and the Makefile uses it correctly afterward: ... ## ---------------- ## ## Cache variables. ## ## ---------------- ## ... ac_cv_env_systemdsystemunitdir_set=set ac_cv_env_systemdsystemunitdir_value=/tmp/test ... pkg_cv_systemdsystemunitdir=/tmp/test ## ----------------- ## ## Output variables. ## ## ----------------- ## ... systemdsystemunitdir='/tmp/test' I had this issue on both Debian 13 (using bash) and Arch Linux (using zsh). -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10480] New: Use after free in cn=config replication
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10480 Issue ID: 10480 Summary: Use after free in cn=config replication 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: --- If a renumber needs to happen, cn=config frees e->e_name, but some code (e.g. syncrepl) sets op->o_req_dn to point to the same and as such it can't be used anymore. This causes a crash in syncrepl (if LDAP_DEBUG_SYNC is on) and accesslog during cn=config replication. Either syncrepl (and others) shouldn't do this or cn=config should check for this case and adjust o_req_dn after the fact. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10524] New: slaptest attempts to open a new database, instead of creating it
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10524 Issue ID: 10524 Summary: slaptest attempts to open a new database, instead of creating it Product: OpenLDAP Version: unspecified 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: --- The issue appears when one decides to convert a slapd.conf file to cn=config, if slapd has never been started with said slapd.conf, and the slapd.conf contains a database definition. For the purpose of testing another issue, I wrote a brand new slapd.conf and attempted to convert it into a brand new configuration directory, before starting up slapd. Example slapd.conf: database config rootdn cn=config rootpw secret database mdb directory ./mdb_test suffix dc=ldap,dc=example,dc=com rootdn cn=admin,dc=ldap,dc=example,dc=com rootpw secret I create the mdb_test directory and the configuration directory (crash.d) and run: slapd -T test -f slap_mdb.conf -F crash.d which fails: mdb_db_open: database "dc=ldap,dc=example,dc=com" cannot be opened: No such file or directory (2). Administrator intervention needed! backend_startup_one (type=mdb, suffix="dc=ldap,dc=example,dc=com"): bi_db_open failed! (2) If I start slapd with the .conf file it starts up sucessfully and createds the database. After that a slaptest run succeeds, because the database already exists. This is probably a rare use case, but I think we need to decide if this is desired behavior and fix it if not. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10535] New: syncprov_play_accesslog issue when consumer up to date with provider but provider dirty
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10535 Issue ID: 10535 Summary: syncprov_play_accesslog issue when consumer up to date with provider but provider dirty 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 the provider state is dirty (changes applied but contextCSN not) and a consumer connects to it with that cookie, syncprov_play_accesslog gets invoked but there is nothing to send. That is currently covered by an assert(). -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10548] New: slapmodify replaces entryUUID
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10548 Issue ID: 10548 Summary: slapmodify replaces entryUUID Product: OpenLDAP Version: 2.6.13 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: dhawes(a)gmail.com Target Milestone: --- When using slapmodify with olcLastMod=TRUE, the entryUUID is replaced for every entry modified. This is undesirable and has implications with syncrepl. The check for lastmod is here: https://git.openldap.org/openldap/openldap/-/blob/master/servers/slapd/slap… Replacing the entryUUID is here: https://git.openldap.org/openldap/openldap/-/blob/master/servers/slapd/slap… More discussion is available at: https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/… -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10556] New: lloadd must not initialize network in tool mode
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10556 Issue ID: 10556 Summary: lloadd must not initialize network in tool mode Product: OpenLDAP Version: 2.6.13 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- This is already fixed incidentally in 2.7 for ITS#10265 commit 89e34fded385ecc59ccaef1fcde2a644df5c4780 Currently the lloadd init always tries to open its listening ports, even if running as a module in slap tools. If lloadd is already running as a daemon, then tools like slapcat will fail to startup because it tries to bind a port that's already in use. The ITS#10265 commit fixes a number of issues, and it can't be directly backported into 2.6. A small fix for this specific point will be added to RE26. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10471] New: lloadd leaks some cn=config values
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10471 Issue ID: 10471 Summary: lloadd leaks some cn=config values Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- ARG_DN/ARG_BERVAL/ARG_STRING tagged options are meant to be saved/freed by the config handler, which lloadd isn't (always) doing. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10469] New: Some TLS option values are leaked on LDAP disposal
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10469 Issue ID: 10469 Summary: Some TLS option values are leaked on LDAP disposal Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- An example (LDAP_OPT_X_TLS_CACERT) is exposed by the autoca test. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10467] New: Alias overlay unitialised variable access
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10467 Issue ID: 10467 Summary: Alias overlay unitialised variable access Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- `source` attribute is not always intialised when used. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9909] New: slap* tools leak cn=config entries on shutdown
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=9909 Issue ID: 9909 Summary: slap* tools leak cn=config entries on shutdown 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: --- slap* tools set up their in-memory cn=config structures but cfb->cb_root is never released on shutdown. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10479] New: syncprov doesn't cleanup abandoned psearch
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10479 Issue ID: 10479 Summary: syncprov doesn't cleanup abandoned psearch Product: OpenLDAP Version: 2.6.13 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- In some cases, revealed in regression test for its#9338, abandoning a psearch doesn't cleanup the search operation. It remains on the connection's c_ops queue indefinitely. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10484] New: lloadd operations_timeout/connection_timeout type confusion
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10484 Issue ID: 10484 Summary: lloadd operations_timeout/connection_timeout type confusion Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- connection_timeout reads unrelated stack memory passed in *arg (operations_timeout passed a time_t which is shorter than struct timeval). Fix is coming -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10470] New: autoca leaks some cn=config values
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10470 Issue ID: 10470 Summary: autoca leaks some cn=config values 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: --- ARG_DN/ARG_BERVAL/ARG_STRING tagged options are meant to be saved/freed by the config handler, which autoca isn't (always) doing. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10525] New: back-ldap accepts multiple tls_cert values in olcDbACLBind
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10525 Issue ID: 10525 Summary: back-ldap accepts multiple tls_cert values in olcDbACLBind Product: OpenLDAP Version: 2.6.13 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: --- In examining my slapd configuration, I found it had: olcDBACLBind: bindmethod=sasl sasl_mech=external tls_cert=/path/to/home/directory/cert tls_cert=/path/to/real/cert <rest of tls configuration> Fortunately it took the second value, so the connections worked, but I would expect this to generate an error -- You are receiving this mail because: You are on the CC list for the issue.

1 4

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

07 Aug '26

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 31

[Issue 10543] New: slapd-read frees the DN pointer array but not the ldap_get_dn() strings
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10543 Issue ID: 10543 Summary: slapd-read frees the DN pointer array but not the ldap_get_dn() strings Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: test suite Assignee: bugs(a)openldap.org Reporter: 1489378385(a)qq.com Target Milestone: --- URL: https://github.com/openldap/openldap/blob/8afcbe9e04f1a40f03cea51c57418b05f… Description: Source revision: 8afcbe9e04f1a40f03cea51c57418b05f86e8f44 Affected file: tests/progs/slapd-read.c Affected lines: 204-232 Source-level observation: do_random() allocates the values pointer array with malloc(). It then calls ldap_get_dn() once for every LDAP search result and stores each independently allocated DN string in values[i]. After the read loop, the code calls: free(values); This releases only the pointer array. It does not release any of the strings returned by ldap_get_dn(). The ldap_get_dn(3) documentation states that its returned string is dynamically allocated and should be released with ldap_memfree(). Steps to verify: 1. Build slapd-read with AddressSanitizer or LeakSanitizer. 2. Run it with a search filter so that do_random() is used. 3. Use a search base containing multiple matching entries. 4. Run multiple outer iterations if possible. 5. Allow the tester to exit and inspect the sanitizer report. Actual result: One DN string remains allocated for every entry returned by each search batch. Only the surrounding values array is freed. Expected result: Every non-NULL value returned by ldap_get_dn() should be released before the values array is freed. Impact: The leak scales with the number of matching entries and the number of outer test iterations. Long or repeated test runs can accumulate substantially more memory than the other three findings. Validation status: Confirmed by source review at the revision above. Runtime sanitizer validation is pending. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10550] New: back ldap idletimeout broken
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10550 Issue ID: 10550 Summary: back ldap idletimeout broken 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: --- When an operation takes longer than idletimeout/conttl, back-ldap decides to terminate the connection. But if that connection is private, it doesn't do it right and asserts in ldap_back_conn_delete Two issues: - the TAINTED flag should not be set without the real state being set to match - a connection with an outstanding operation shouldn't be considered idle -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 8064] SIGSEGV in monitor-shutdown code
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

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

1 0

[Issue 10473] New: syncprov leaks response controls
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10473 Issue ID: 10473 Summary: syncprov leaks response controls 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_state_ctrl and syncprov_done_ctrl add controls to the response, but noone cares to free them afterwards assuming they are allocated from the slab. If there are many messages sent in a single run, this takes up fresh memory that's leaked eventually. See its8800 regression test for an example where this happens. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10541] New: syncrepl regression with older format of entryCSN
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10541 Issue ID: 10541 Summary: syncrepl regression with older format of entryCSN Product: OpenLDAP Version: 2.6.13 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: benp(a)reed.edu Target Milestone: --- We recently upgraded from openldap 2.6.10 to 2.6.13 (using debian packages from symas.com). Subsequent to the upgrade we noticed that syncrepl was sometimes failing to replicate changes to entries. It appears that the behavior is triggered when modifying an entry with an older style entryCSN (eg "entryCSN: 20210115230536Z#000001#00#000000" vs the current style "entryCSN: 20260715174316.844052Z#000000#001#000000"). The updated entry on the provider slapd gets a new entryCSN that uses the new format, but the consumer slapds don't process the changes made to the entry, and log a failed assertion (122) error like this: Jul 8 10:39:28 slapd-c daemon.info slapd[129831]: 6a3f4436.0d08671e 0x7f6d411fc6c0 syncrepl_entry: rid=011 be_modify uid=example-user,ou=People,dc=foo,dc=bar (122) Deleting the problematic entry on the provider and then recreating it tends to resolve the issue for us, presumably because the new entry has the normal non-obsolete contextCSN attribute. Our current production DB has ~22k entries, ~4k of which have older style contextCSNs, so we'd love to avoid having to delete and recreate those ~4k entries if we don't have to. We have entryCSNs in at least 3 different formats: entryCSN: 2003081423:11:31Z#0x000d#0#0000 entryCSN: 20230410142047Z#000000#00#000000 entryCSN: 20260313112653.221151Z#000000#001#000000 Our current configuration does not use accesslog, so replication is simple syncrepl (vs delta-syncrepl). It was suggested on the openldap-technical list that we consider filing an ITS about this issue. Please let me know what additional supporting information would be helpful. I'm not totally certain how to distill are slapd.d style config to something concise enough for the bug tracker. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10475] slapo-constraint URI mode fails to escape assertion values in internal catalog filters, enabling wildcard/filter-metachar allowlist bypass
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

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

1 0

[Issue 10528] New: core.ldif fails to load via "include:" in cn=config on Symas OpenLDAP 2.6.13-3 (RHEL 9)
by openldap-its＠openldap.org 07 Aug '26

07 Aug '26

https://bugs.openldap.org/show_bug.cgi?id=10528 Issue ID: 10528 Summary: core.ldif fails to load via "include:" in cn=config on Symas OpenLDAP 2.6.13-3 (RHEL 9) Product: OpenLDAP Version: 2.6.13 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: lucas.vicente(a)ebz.tec.br Target Milestone: --- Hello, We are experiencing an issue while trying to load the core.ldif schema default using the dynamic configuration (cn=config). When using the following in my LDIF: include: file:///opt/symas/etc/openldap/schema/core.ldif I get this error: olcAttributeTypes: value #48 olcAttributeTypes: Unexpected token before MUST c MAY ( searchGuide $ description ) ) slapadd: could not add entry dn="cn={0}core,cn=schema,cn=config" (line=14): olcAttributeTypes: Unexpected token before MUST c MAY ( searchGuide $ description ) ) Obs: If I create a slapd.conf that includes the core schema and run: slaptest -f slapd.conf -F /tmp/slapd.d It works without errors. However, when trying to load the same schema using slapadd + include: in cn=config, it fails. For reference, I tested the same steps on version 2.6.10 and it worked without errors. Steps to reproduce: Install Symas OpenLDAP 2.6.13 on RHEL 9 Try to load the core schema using: dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema include: file:///opt/symas/etc/openldap/schema/core.ldif Would you be able to verify this behavior? Thanks! -- You are receiving this mail because: You are on the CC list for the issue.

1 2

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs