openldap-bugs September 2021

openldap-bugs@openldap.org

1 participants
193 discussions

[Issue 9643] New: back-wt: entry_decode failure.
by openldap-its＠openldap.org 25 Oct '21

25 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=9643 Issue ID: 9643 Summary: back-wt: entry_decode failure. Product: OpenLDAP Version: 2.5.6 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: hamano(a)osstech.co.jp Target Milestone: --- https://bugs.openldap.org/show_bug.cgi?id=9463 ondra mentioned: > e.g. ./run -b wt -l 50 test034 I reproduced the issue by iterating test034. And I figure out the issue is in entry_encode/decode. It happens stochastically by reading memory outside the malloc area when decoding special entry (only dn entry without attributes). Since entry_encode/decode was originally used by back-bdb and back-hdb, these backends also had this problem. Currently It seems that only back-wt is using entry_encode/decode. I'll fork entry_encode/decode and create wt_entry_encode/decode. Then, we can remove entry_encode/decode. -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 9636] New: delete back-shell
by openldap-its＠openldap.org 25 Oct '21

25 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=9636 Issue ID: 9636 Summary: delete back-shell Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- The back-shell backend was removed starting with OpenLDAP 2.5. It should also be removed from the head development branch. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9635] New: Delete back-ndb
by openldap-its＠openldap.org 25 Oct '21

25 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=9635 Issue ID: 9635 Summary: Delete back-ndb Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- The back-ndb backend is deprecated and given Oracle's unwillingness to further defvelopment it is a dead project. Time to remove it. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9670] New: Roadmap has bogus items for 2.6/2.7
by openldap-its＠openldap.org 25 Oct '21

25 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=9670 Issue ID: 9670 Summary: Roadmap has bogus items for 2.6/2.7 Product: website Version: unspecified Hardware: All URL: https://openldap.org/software/roadmap.html OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- - lloadd has supported "all" LDAP operation types since being merged in 2.5 - both ppolicy enhancements are bogus too - logging landed in 2.6 already -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9645] New: Documentation upgrading from 2.4 - two descriptions
by openldap-its＠openldap.org 11 Oct '21

11 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=9645 Issue ID: 9645 Summary: Documentation upgrading from 2.4 - two descriptions Product: OpenLDAP Version: 2.5.4 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- Searching in Internet for “upgrade openldap 2.5” finds • https://www.openldap.org/devel/admin/appendix-upgrading.html, and • https://www.openldap.org/doc/admin25/appendix-upgrading.html The text at the former link is incomplete, compared to the latter link. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9711] New: olcTLSVerifyClient set incorrectly on conversion
by openldap-its＠openldap.org 11 Oct '21

11 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=9711 Issue ID: 9711 Summary: olcTLSVerifyClient set incorrectly on conversion Product: OpenLDAP Version: 2.5.7 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 converting the following slapd.conf to cn=config via slaptest, the olcTLSVerifyClient parameter is set to "demand" instead of "never". The slapd.conf man page clearly states that "never" is supposed to be the default. This causes startTLS operations to fail from the client. slapd.conf: include /opt/symas/etc/openldap/schema/core.schema pidfile /var/symas/run/slapd.pid argsfile /var/symas/run/slapd.args loglevel stats TLSCACertificateFile /opt/symas/ssl/CA/certs/testsuiteCA.crt TLSCertificateFile /opt/symas/ssl/certs/ub18.crt TLSCertificateKeyFile /opt/symas/ssl/private/ub18.key modulepath /opt/symas/lib/openldap moduleload back_mdb.la database config rootpw secret database mdb maxsize 1073741824 suffix "dc=my-domain,dc=com" rootdn "cn=Manager,dc=my-domain,dc=com" rootpw secret directory /var/symas/openldap-data index objectClass eq database monitor With the above slapd.conf, the following ldapsearch command succeeds: /opt/symas/bin/ldapsearch -x -ZZ -H ldap://ub18.quanah.org/^ However, after converting it to cn=config: slaptest -f slapd.conf -F /opt/symas/etc/openldap/slapd.d olcTLSVerifyClient has an incorrect value of "demand" instead of "never": cn=config.ldif:olcTLSVerifyClient: demand -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9679] New: On mariadb 10.5 the sql for creating the main definitions fails with errno: 150 "Foreign key constraint is incorrectly formed
by openldap-its＠openldap.org 11 Oct '21

11 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=9679 Issue ID: 9679 Summary: On mariadb 10.5 the sql for creating the main definitions fails with errno: 150 "Foreign key constraint is incorrectly formed Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: lukav(a)lukav.com Target Milestone: --- Created attachment 841 --> https://bugs.openldap.org/attachment.cgi?id=841&action=edit Attached patch that fixes the issue When you try to execute servers/slapd/back-sql/rdbms_depend/mysql/backsql_create.sql in mariadb 10.5 you get an error: Fix Can't create table `ldap`.`ldap_entry_objclasses` (errno: 150 "Foreign key constraint is incorrectly formed") That is because entry_id column is not declared unsigned as the ldap_entries(id) column. This patch fixed the definition. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9678] New: slapadd prints “olcRootPW: value #0: <olcRootPW> can only be set when rootdn is under suffix” and then crashes
by openldap-its＠openldap.org 11 Oct '21

11 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=9678 Issue ID: 9678 Summary: slapadd prints “olcRootPW: value #0: <olcRootPW> can only be set when rootdn is under suffix” and then crashes Product: OpenLDAP Version: 2.5.7 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- Created attachment 840 --> https://bugs.openldap.org/attachment.cgi?id=840&action=edit Valgrind output Calling ``` slapadd -n0 -F/home/d/ldap/conf <<ABC dn: cn=config objectClass: olcGlobal cn: config olcAuthzRegexp: uid=([^@,]+)@example.org,cn=[^,]*,cn=auth uid=$1,cn=users,dc=example,dc=org dn: olcDatabase=frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: frontend dn: olcDatabase=config,cn=config objectClass: olcDatabaseConfig olcDatabase: config olcRootDN: uid=yyy,cn=users,dc=example,dc=org olcRootPW: zzz ABC ``` prints PROXIED attributeDescription "DC" inserted. olcRootPW: value #0: <olcRootPW> can only be set when rootdn is under suffix slapadd: could not add entry dn="olcDatabase={0}config,cn=config" (line=12): Segmentation fault (core dumped) The output of valgrind, when it runs the above command, is attached. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9671] New: pwdPolicySubentry: no user modification allowed
by openldap-its＠openldap.org 11 Oct '21

11 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=9671 Issue ID: 9671 Summary: pwdPolicySubentry: no user modification allowed Product: OpenLDAP Version: 2.5.7 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: michael(a)stroeder.com Target Milestone: --- Without using Relax Rules control it is not possible to set attribute pwdPolicySubentry anymore. This was possible with 2.4.x. # ldapadd -Q -f aehost.ldif adding new entry "host=foobar42.example.com,cn=test-hosts-1,cn=test,ou=ae-dir" ldap_add: Constraint violation (19) additional info: pwdPolicySubentry: no user modification allowed This is a really serious regression for existing admin processes. -- You are receiving this mail because: You are on the CC list for the issue.

1 14

[Issue 9664] New: Hiding namingContexts in the root DSE, when these are not in small letters
by openldap-its＠openldap.org 11 Oct '21

11 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=9664 Issue ID: 9664 Summary: Hiding namingContexts in the root DSE, when these are not in small letters Product: OpenLDAP Version: 2.5.6 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- Below are the ACL for the frontend database. They are supposed to hide the cn=krbconfig from the namingContexts on the root DSE. dn: olcDatabase=frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: frontend #olcAccess: to dn.base="" attrs=namingContexts val/distinguishedNameMatch="cn=krbcontainer" by * none olcAccess: to dn.base="" attrs=namingContexts val="cn=krbcontainer" by * none olcAccess: to dn.exact="" by * read dn: olcDatabase=mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: mdb olcDbMaxSize: 10485760 olcSuffix: cn=krbcontainer olcRootDN: uid=zzz,cn=krbcontainer olcRootPW: zzz olcDbDirectory: ldap/uuu olcDbIndex: objectClass eq olcAccess: to dn.sub="cn=krbContainer" by * read It does work! However, if change the case in (container ⇒ Container): olcSuffix: cn=krbContainer no matter how I set olcAccess in the frontend database, $ ldapsearch -xb "" -s base namingContexts always prints dn: namingContexts: cn=krbContainer In particular olcAccess: to dn.base="" attrs=namingContexts val/distinguishedNameMatch="cn=krbcontainer" by * none does not hide it. • It shall be possible to find olcSuffix from the DSE/namingContexts, even if the suffix is mixCased. Since the case is known at the time, when the rules are written, OpenLDAP shall offer an option for exact match, without converting data to lowercase. (as shown by sladp -d -1 ) -- You are receiving this mail because: You are on the CC list for the issue.

1 8

← Newer
1
...
7
8
9
10
11
12
13
...
20
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 September 2021