openldap-bugs July 2022

openldap-bugs@openldap.org

1 participants
111 discussions

[Issue 9827] New: Feature request for module argon2.so to support Argon2i, Argon2d, Argon2id
by openldap-its＠openldap.org 26 Nov '24

26 Nov '24

https://bugs.openldap.org/show_bug.cgi?id=9827 Issue ID: 9827 Summary: Feature request for module argon2.so to support Argon2i, Argon2d, Argon2id 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: juergen.sprenger(a)swisscom.com Target Milestone: --- Hi, This is a feature request. I would like to be able to chooses between Argon2i, Argon2d and Argon2id in slappasswd like in argon2 command: # argon2 Usage: argon2 [-h] salt [-i|-d|-id] [-t iterations] [-m log2(memory in KiB) | -k memory in KiB] [-p parallelism] [-l hash length] [-e|-r] [-v (10|13)] Password is read from stdin Parameters: salt The salt to use, at least 8 characters -i Use Argon2i (this is the default) -d Use Argon2d instead of Argon2i -id Use Argon2id instead of Argon2i -t N Sets the number of iterations to N (default = 3) -m N Sets the memory usage of 2^N KiB (default 12) -k N Sets the memory usage of N KiB (default 4096) -p N Sets parallelism to N threads (default 1) -l N Sets hash output length to N bytes (default 32) -e Output only encoded hash -r Output only the raw bytes of the hash -v (10|13) Argon2 version (defaults to the most recent version, currently 13) -h Print argon2 usage Example: /usr/local/etc/openldap # /usr/sbin/slappasswd -h "{ARGON2}" -o module-load="argon2.so i" -s secret /usr/local/etc/openldap # /usr/sbin/slappasswd -h "{ARGON2}" -o module-load="argon2.so d" -s secret /usr/local/etc/openldap # /usr/sbin/slappasswd -h "{ARGON2}" -o module-load="argon2.so id" -s secret Best regards Juergen Sprenger -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[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

[Bug 9211] New: Relax control is not consistently access-restricted
by openldap-its＠openldap.org 25 Oct '24

25 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=9211 Bug ID: 9211 Summary: Relax control is not consistently access-restricted Product: OpenLDAP Version: 2.4.49 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ryan(a)openldap.org Target Milestone: --- The following operations can be performed by anyone having 'write' access (not even 'manage') using the Relax control: - modifying/replacing structural objectClass - adding/modifying OBSOLETE attributes Some operations are correctly restricted: - adding/modifying NO-USER-MODIFICATION attributes marked as manageable (Modification of non-conformant objects doesn't appear to be implemented at all.) In the absence of ACLs for controls, I'm of the opinion that all use of the Relax control should require manage access. The Relax draft clearly and repeatedly discusses its use cases in terms of directory _administrators_ temporarily relaxing constraints in order to accomplish a specific task. -- You are receiving this mail because: You are on the CC list for the bug.

1 13

[Issue 9596] New: Python test suite
by openldap-its＠openldap.org 24 Oct '24

24 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=9596 Issue ID: 9596 Summary: Python test suite Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- The bash test suite is extremely limited, hard to write for and slow. We can't lose it as it is also portable, but something should be introduced for developers/CI on more modern systems and increase coverage. A Python 3 seed for one is in development in MR!347. -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 9786] New: liblber: missing export of ber_pvt_wsa_err2string
by openldap-its＠openldap.org 22 Oct '24

22 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=9786 Issue ID: 9786 Summary: liblber: missing export of ber_pvt_wsa_err2string Product: OpenLDAP Version: 2.6.1 Hardware: All OS: Windows Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: tobias.junghans(a)veyon.io Target Milestone: --- When building (cross-compiling) OpenLDAP via GCC/mingw-w64, an undefined reference to ber_pvt_wsa_err2string() is reported when libldap.dll is linked. This can be fixed easily by adding ber_pvt_wsa_err2string() to libraries/liblber/lber.map -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9881] New: Ability to track last authentication for database objects
by openldap-its＠openldap.org 15 Oct '24

15 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=9881 Issue ID: 9881 Summary: Ability to track last authentication for database objects Product: OpenLDAP Version: unspecified 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: --- For simple binds, we have the ability to track the last success via the lastbind functionality (pwdLastSuccess attribute). However this doesn't allow one to see when an object that exists in a database last authenticated via SASL. It would be useful to add similar functionality for SASL binds. This can be useful information that allows one to tell if an object is being actively authenticated to (generally, users and system accounts, etc). Obviously if something is directly mapped to an identity that doesn't exist in the underlying DB, that cannot be tracked. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Bug 9220] New: Rewrite Bind and Exop result handling
by openldap-its＠openldap.org 15 Oct '24

15 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=9220 Bug ID: 9220 Summary: Rewrite Bind and Exop result handling Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Bind and Exop result handling needs a rewrite so it is no longer a special case for overlays. -- You are receiving this mail because: You are on the CC list for the bug.

1 8

[Issue 9640] New: ACL privilege for MOD_INCREMENT
by openldap-its＠openldap.org 15 Oct '24

15 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=9640 Issue ID: 9640 Summary: ACL privilege for MOD_INCREMENT Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: michael(a)stroeder.com Target Milestone: --- I'm using LDAP write operations with MOD_INCREMENT with pre-read-control for uidNumber/gidNumber generation. I'd like to limit write access to an Integer attribute "nextID" to MOD_INCREMENT, ideally even restricting the de-/increment value. (Uniqueness is achieved with slapo-unique anyway but still I'd like to avoid users messing with this attribute). IMHO the ideal solution would be a new privilege "i". Example for limiting write access to increment by one and grant read access for using read control: access to attrs=nextID val=1 by group=... =ri Example for decrementing by two without read: access to attrs=nextID val=-2 by group=... =i -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9356] New: Add list of peerSIDs to consumer cookie to reduce cross traffic
by openldap-its＠openldap.org 15 Oct '24

15 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=9356 Issue ID: 9356 Summary: Add list of peerSIDs to consumer cookie to reduce cross traffic Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- If we add a list of peersids to the cookie, each consumer can tell the providers who else the consumers talk to and then the provider can omit sending updates to that consumer, originating from those peers There's some special handling needed if a connection dies If a consumer loses one of its peer connections, and after N retries is still not connected, it should send a new cookie to its remaining peers saying "here's my new peer list" with the missing one removed. Likewise, if a retry eventually connects again, it can send a new cookie again Make that peer list reset configurable in the syncrepl config stanza. This can help account for end admin knowledge that some links may be more or less stable than other ones. The idea here is that if one of your other peers can still see the missing peer, they can start routing updates to you again It should abandon all existing persist sessions and send a new sync search with the new cookie to all remaining peers For consumer side, also means adding the sid for a given provider into the syncrepl stanza to save on having to try and discover the peer sid. -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 9272] New: Invalid search results for subordinate/glued database
by openldap-its＠openldap.org 15 Oct '24

15 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=9272 Issue ID: 9272 Summary: Invalid search results for subordinate/glued database Product: OpenLDAP Version: 2.4.47 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: grapvar(a)gmail.com Target Milestone: --- Here is a trivial test case. Look at the following bunch of glued dit's/databases, declared in this order: | suffix ou=a,ou=1,ou=T # subordinate; contains only one (top-level) entry | suffix ou=2,ou=T # subordinate; contains only one (top-level) entry | suffix ou=b,ou=1,ou=T # subordinate; contains only one (top-level) entry | suffix ou=T # master database, has two entries, top-level | ` ou=1 # ... and this child entry let's query the united database: | $ ldapsearch -b ou=1,ou=T -s sub '' nx | dn: ou=1,ou=T | dn: ou=a,ou=1,ou=T | dn: ou=b,ou=1,ou=T Nice! But wait, what if ... | $ ldapsearch -b ou=1,ou=T -s sub -E\!pr=2/noprompt '' nx | dn: ou=1,ou=T | dn: ou=a,ou=1,ou=T | | # pagedresults: cookie=//////////8= ... BANG! ... | Server is unwilling to perform (53) The problem is the glue_op_search(), which has issues * different parts of code make different assumptions about data structures * different parts of code track state inconsistently * code that looks like a highly probably dead code I mean that likely possible to build another bug-triggering test cases, and glue_op_search() needs not just a fix of the bug above, but intense cleaning and structuring. -- You are receiving this mail because: You are on the CC list for the issue.

1 14

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs July 2022