openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

[Issue 7441] cn=config filters ignore {number}
by openldap-its＠openldap.org 07 Mar '22

07 Mar '22

https://bugs.openldap.org/show_bug.cgi?id=7441 --- Comment #2 from Ondřej Kuzník <ondra(a)mistotebe.net> --- The inconsistency part comes from bconfig not implementing be_compare. Instead, it relies on the frontend implementation, so while search goes through test_filter->...->ordered_value_match and other backends use slap_compare_entry which triggers the same, frontend's compare gets the actual values through backend_attribute and then calls value_find_ex, which doesn't care about SLAP_AT_ORDERED. Afterwards, allowing attr={index} assertions to match attr={index}value and attr={index}value to match itself only should be possible by adapting ordered_value_match (and value_find_ex or whatever we end up calling from the frontend). -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9748] New: Deleted values of pwdFailureTime seem to reappear
by openldap-its＠openldap.org 03 Mar '22

03 Mar '22

https://bugs.openldap.org/show_bug.cgi?id=9748 Issue ID: 9748 Summary: Deleted values of pwdFailureTime seem to reappear 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: --- Created attachment 854 --> https://bugs.openldap.org/attachment.cgi?id=854&action=edit accesslog for uid=dm01-R2H2-956,ou=People,dc=example,dc=com Somehow, ppolicy seems to be able to reference values of pwdFailureTime that had been deleted before the actual bind even started. In the attached accesslog, trace, deletion of everything (including "20211115154510.478330Z") is recorded from reqSession: 3, then a bind comes in and the same value is explicitly removed again. -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 9800] New: ACL with set.expand in <who> clause does not work with deref control
by openldap-its＠openldap.org 03 Mar '22

03 Mar '22

https://bugs.openldap.org/show_bug.cgi?id=9800 Issue ID: 9800 Summary: ACL with set.expand in <who> clause does not work with deref control Product: OpenLDAP Version: 2.6.1 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: michael(a)stroeder.com Target Milestone: --- This ACL returns correct values with a normal search requesting the attribute sudoUser: access to dn.subtree="ou=ae-dir" attrs=sudoUser val.regex="^%(.+)$" by set.expand="(user/-1 | user/aeSrvGroup)/aeLoginGroups & [ldap:///ou=ae-dir?entryDN?sub?(&(objectClass=aeGroup)(aeStatus=0)(cn=${v1}))]/entryDN" read by * none But it does not work with a search like this using deref control: ldapsearch -Q -E deref=aeVisibleSudoers:cn,sudoUser '(objectClass=aeSrvGroup)' For completeness see docs and schema for aeSrvGroup: https://www.ae-dir.com/docs.html#schema-oc-aeSrvGroup https://code.stroeder.com/AE-DIR/ansible-ae-dir-server/src/branch/master/fi… -- You are receiving this mail because: You are on the CC list for the issue.

1 1

[Issue 7335] Create process for updating man pages to handle both cn=config and slapd.conf configurations
by openldap-its＠openldap.org 28 Feb '22

28 Feb '22

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

1 0

[Bug 9256] New: The ACLs required for SASL binding are not fully documented
by openldap-its＠openldap.org 28 Feb '22

28 Feb '22

https://bugs.openldap.org/show_bug.cgi?id=9256 Bug ID: 9256 Summary: The ACLs required for SASL binding are not fully documented Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: kop(a)karlpinc.com Target Milestone: --- Created attachment 727 --> https://bugs.openldap.org/attachment.cgi?id=727&action=edit Patch massaging the SASL binding requirement docs While some ACL requirements for SASL binding are documented, some are not. E.g, that olcAuthzRegexp requires =x on objectClass when direct DN mapping is not documented. Other requirements can be reasoned out based on the existing documentation, but this can be very difficult when unfamiliar with all the moving parts and the places they are documented. E.g. knowing that (objectClass=*) is the default filter, and that there's _always_ _some_ filter, and connecting this with ACLs required to do search-based SASL mapping. The attached patch brings all the SASL binding requirements together in one place in the docs and makes everything explicit. The word "SASL" is included, for those searching for that keyword. I, Karl O. Pinc, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. -- You are receiving this mail because: You are on the CC list for the bug.

1 27

[Issue 9731] New: startup messages still go to syslog when logfile-only is on
by openldap-its＠openldap.org 28 Feb '22

28 Feb '22

https://bugs.openldap.org/show_bug.cgi?id=9731 Issue ID: 9731 Summary: startup messages still go to syslog when logfile-only is on Product: OpenLDAP Version: 2.6.0 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 setting logfile-only on, slapd still logs its startup message to syslog: Oct 29 21:07:47 u18test slapd[18534]: @(#) $OpenLDAP: slapd 2.6.0 (Oct 29 2021 05:12:17) $#012#011openldap This is useful information to have consolidated into the specified logfile. Note that: 617c62a3.16f03fdb 0x7f9325ed67c0 slapd starting does make it to the logfile. However, it would be useful to have the build date and version in the specified logfile. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 6097] MMR problems with deletes
by openldap-its＠openldap.org 28 Feb '22

28 Feb '22

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

1 0

[Issue 8255] slapd-sock: response parsing in str2result() is broken
by openldap-its＠openldap.org 28 Feb '22

28 Feb '22

https://bugs.openldap.org/show_bug.cgi?id=8255 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|IN_PROGRESS |RESOLVED --- Comment #12 from Quanah Gibson-Mount <quanah(a)openldap.org> --- RE26: • 59605f9f by Ondřej Kuzník at 2022-02-28T17:36:11+00:00 ITS#8255 Clarify "sockresps result" behaviour -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8255] slapd-sock: response parsing in str2result() is broken
by openldap-its＠openldap.org 28 Feb '22

28 Feb '22

https://bugs.openldap.org/show_bug.cgi?id=8255 --- Comment #11 from Quanah Gibson-Mount <quanah(a)openldap.org> --- head: 73e882c8 by Ondřej Kuzník at 2022-02-24T15:32:36+00:00 ITS#8255 Clarify "sockresps result" behaviour -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8753] Public key pinning support in libldap
by openldap-its＠openldap.org 21 Feb '22

21 Feb '22

https://bugs.openldap.org/show_bug.cgi?id=8753 --- Comment #14 from Ondřej Kuzník <ondra(a)mistotebe.net> --- On Mon, Feb 21, 2022 at 10:46:12AM +0000, openldap-its(a)openldap.org wrote: > => The correct values for hashalgo should be described in the man-page. Since this depends entirely on the crypto library at runtime, not sure how we could do any better than saying "it depends", which is what I did in that linked commit, now at https://git.openldap.org/openldap/openldap/-/merge_requests/499 Can you suggest an alternate wording you think explains it better? Thanks, -- You are receiving this mail because: You are on the CC list for the issue.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs