May 2021 - openldap-bugs

[Issue 9385] New: Opening an env with MDB_NOSUBDIR with no existing file returns error

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9385 Issue ID: 9385 Summary: Opening an env with MDB_NOSUBDIR with no existing file returns error Product: LMDB Version: unspecified Hardware: All OS: Mac OS Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: kriszyp(a)gmail.com Target Milestone: --- Created attachment 776 --> https://bugs.openldap.org/attachment.cgi?id=776&action=edit A fix to tolerate stat call on non-existing file Calling mdb_env_open with a file path to a file that doesn't exist yet, with MDB_NOSUBDIR on a non-Windows OS will return an error indicating that the file doesn't exist. This is supposed to create a new file, and works properly on the mdb.master branch, and still functions properly on Windows. The error is due to the stat() call in mdb_env_open prior to the file existing. I attached a patch that tolerates the absence of the file before checking if the file is on a block device. I am not sure if this is the appropriate fix, or if would be better to move this check later in mdb_env_open after the file is created, or alternately, determining the parent directory and calling stat on that. -- You are receiving this mail because: You are on the CC list for the issue.

1 year, 4 months

1
1
0 / 0

[Issue 9403] New: add option to completely disable syslog logging

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9403 Issue ID: 9403 Summary: add option to completely disable syslog logging Product: OpenLDAP Version: 2.4.45 Hardware: All OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: cvuillemez(a)yahoo.fr Target Milestone: --- For auditing purpose, I need to enable "stats" loglevel. So on heavy load, slapd send lots of events to local syslog socket /dev/log, when compiled with LDAP_SYSLOG (on Debian / Ubuntu). It worked fine on old systems with a simple syslog service. But when upgrading on system with journald+syslog, CPU "overhead" becomes totally crazy. It would be great to have an option at run time to completely disable syslog logging, or/and use a cutom socket, e.g. /run/systemd/journal/syslog to bypass journald service. -- You are receiving this mail because: You are on the CC list for the issue.

1 year, 4 months

1
3
0 / 0

[Issue 9497] New: back-ldif: test022-ppolicy failure

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9497 Issue ID: 9497 Summary: back-ldif: test022-ppolicy failure Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: hamano(a)osstech.co.jp Target Milestone: --- The test022-ppolicy with back-ldif fail for two issue. 1. too short pwdMaxAge ~~~ $ ./run -b ldif test022-ppolicy (snip) Testing password expiration Waiting seconds for password to expire... sleep: missing operand Try 'sleep --help' for more information. Password expiration test failed ~~~ The script tries test for lockout and then a test for password expiration. It will fail if the password has expired(pwdMaxAge: 30) by the time it starts the password expiration test. This is a timing issue and not directly caused by back-ldif. However, the issue is reproduced only with back-ldif in my environment. This test passed in my environment by extending pwdMaxAge by 5 seconds, but there may be a better way. 2. duplicate ldap control response ~~~ Reconfiguring policy to remove grace logins... Clearing forced reset... expr: syntax error: unexpected argument '15' Testing password expiration Waiting seconds for password to expire... sleep: missing operand Try 'sleep --help' for more information. ~~~ This is back-ldif issue. back-ldif responds duplicate ldap control response. -- You are receiving this mail because: You are on the CC list for the issue.

1 year, 7 months

1
8
0 / 0

[Bug 9256] New: The ACLs required for SASL binding are not fully documented

by openldap-its＠openldap.org

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 year, 7 months

1
27
0 / 0

[Issue 9502] New: Implement TCP_USER_TIMEOUT in meta and asyncmeta

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9502 Issue ID: 9502 Summary: Implement TCP_USER_TIMEOUT in meta and asyncmeta Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- Implement TCP_USER_TIMEOUT as an option to libldap and as a configuration option in back-meta and back-asyncmeta -- You are receiving this mail because: You are on the CC list for the issue.

1 year, 7 months

1
9
0 / 0

[Bug 9189] New: Add GSSAPI channel-bindings support

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9189 Bug ID: 9189 Summary: Add GSSAPI channel-bindings support Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: iboukris(a)gmail.com Target Milestone: --- Recently MS has announce they plan to enforce channel-bindings for LDAP over TLS (ADV190023). To support it on client side, we need to pass "tls-endpoint" bindings (RFC 5929) to the SASL plugin, and make use of that in GSSAPI. See also: https://github.com/cyrusimap/cyrus-sasl/pull/601 -- You are receiving this mail because: You are on the CC list for the bug.

1 year, 7 months

1
13
0 / 0

[Issue 9350] New: Expand test suite for null base

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9350 Issue ID: 9350 Summary: Expand test suite for null base Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Currently we have no tests that use the empty suffix (null base). This is an entirely valid configuration setup, and there are unique challenges and bugs that crop up with this usage. We need to ensure we're covering this use case, particularly with syncrepl and delta-syncrepl configurations. -- You are receiving this mail because: You are on the CC list for the issue.

1 year, 8 months

1
4
0 / 0

[Issue 9538] New: Accesslog entryCSN ordering is not always monotonous

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9538 Issue ID: 9538 Summary: Accesslog entryCSN ordering is not always monotonous Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- For delta-sync replication, we rely on CSN order being preserved at all times. When logops includes anything more than "writes", we don't use li_op_rmutex to maintain serialisation. A concurrent write and another operation (like bind) can have the write have its csn assigned before the bind. But before the write finishes on the main DB and is logged, the bind has already hit accesslog. This entry out of order doesn't match the usual filter, so non-persist sessions will not notice, however running persist sessions could get a new cookie sent, depending on how things are ordered when they hit syncprov. A sample: ---- 8< ---- Apr 26 19:56:04 localhost slapd[43930]: conn=1003 op=41 ADD dn="uid=dm01-R1H2-41660,ou=People,dc=example,dc=com" Apr 26 19:56:04 localhost slapd[43930]: conn=1003 op=41 syncprov_matchops: recording uuid for dn=reqStart=20210426195604.000350Z,cn=accesslog on opc=0x7d3d2800dc50 Apr 26 19:56:04 localhost slapd[43930]: slap_get_csn: conn=1003 op=42 generated new csn=20210426195604.556053Z#000000#002#000000 manage=1 Apr 26 19:56:04 localhost slapd[43930]: slap_queue_csn: queueing 0x7d3d38148f60 20210426195604.556053Z#000000#002#000000 Apr 26 19:56:04 localhost slapd[43930]: conn=1005 op=1 BIND dn="dc=example,dc=com" method=128 Apr 26 19:56:04 localhost slapd[43930]: conn=1005 op=1 BIND dn="dc=example,dc=com" mech=SIMPLE bind_ssf=0 ssf=256 Apr 26 19:56:04 localhost slapd[43930]: conn=1003 op=41 RESULT tag=105 err=0 qtime=0.005874 etime=0.015182 text= Apr 26 19:56:04 localhost slapd[43930]: slap_get_csn: conn=1005 op=1 generated new csn=20210426195604.558683Z#000000#002#000000 manage=1 Apr 26 19:56:04 localhost slapd[43930]: slap_queue_csn: queueing 0x561f09113f80 20210426195604.558683Z#000000#002#000000 Apr 26 19:56:04 localhost slapd[43930]: conn=1005 op=1 syncprov_matchops: recording uuid for dn=reqStart=20210426195604.000364Z,cn=accesslog on opc=0x561f0900fcf0 Apr 26 19:56:04 localhost slapd[43930]: conn=1002 op=2 syncprov_qresp: set up a new syncres mode=4 csn=20210426195604.558683Z#000000#002#000000 Apr 26 19:56:04 localhost slapd[43930]: conn=1001 op=2 syncprov_qresp: set up a new syncres mode=4 csn=20210426195604.558683Z#000000#002#000000 Apr 26 19:56:04 localhost slapd[43930]: conn=1000 op=2 syncprov_qresp: set up a new syncres mode=4 csn=20210426195604.558683Z#000000#002#000000 Apr 26 19:56:04 localhost slapd[43930]: slap_graduate_commit_csn: removing 0x561f09113f80 20210426195604.558683Z#000000#002#000000 Apr 26 19:56:04 localhost slapd[43930]: conn=1005 op=1 RESULT tag=97 err=0 qtime=0.000020 etime=0.004297 text= Apr 26 19:56:04 localhost slapd[43930]: slap_queue_csn: queueing 0x7d3d38148250 20210426195604.556053Z#000000#002#000000 Apr 26 19:56:04 localhost slapd[43930]: slap_graduate_commit_csn: removing 0x7d3d38148250 20210426195604.556053Z#000000#002#000000 Apr 26 19:56:04 localhost slapd[43930]: slap_graduate_commit_csn: removing 0x7d3d38148f60 20210426195604.556053Z#000000#002#000000 ---- 8< ---- Example entries in the order slapcat sees them: ---- 8< ---- dn: reqStart=20210426195604.000364Z,cn=accesslog objectClass: auditBind reqStart: 20210426195604.000364Z reqEnd: 20210426195604.000365Z reqType: bind entryCSN: 20210426195604.558683Z#000000#002#000000 dn: reqStart=20210426195604.000351Z,cn=accesslog objectClass: auditAdd reqStart: 20210426195604.000351Z reqEnd: 20210426195604.000366Z reqType: add entryCSN: 20210426195604.556053Z#000000#002#000000 ---- 8< ---- -- You are receiving this mail because: You are on the CC list for the issue.

1 year, 8 months

1
20
0 / 0

[Issue 9556] New: slapd-config should return invalidAttributeSyntax if parsing schema description fails

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9556 Issue ID: 9556 Summary: slapd-config should return invalidAttributeSyntax if parsing schema description fails Product: OpenLDAP Version: 2.5.4 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 currently testing error handling and interacting with LDAP clients (e.g. my web2ldap). Sending an invalid attribute type description results in an error (as expected) returned by slapd-config: RESULT tag=103 err=80 qtime=0.000032 etime=0.001271 text=olcAttributeTypes: Unexpected token before SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) But result code other(80) seems not very useful. It's too unspecific to decide on specific error handling. It would be much more useful if slapd-config returns invalidAttributeSyntax(21) in this case. -- You are receiving this mail because: You are on the CC list for the issue.

1 year, 8 months

1
6
0 / 0

[Issue 9493] New: slapo-accesslog handling of deletion of multi-valued configuration attributes removes wrong value from list

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9493 Issue ID: 9493 Summary: slapo-accesslog handling of deletion of multi-valued configuration attributes removes wrong value from list Product: OpenLDAP Version: 2.4.57 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: svella(a)technologist.com Target Milestone: --- I observed this in the debugger while working on a small feature addition to slapo-accesslog. log_cf_gen(), when handling the initial configuration of oldAccessLogOldAttr (accesslog.c:989), linked list li_oldattrs is being built by inserting each value in order at the head of the list, resulting in the list being in reverse order. But when handling LDAP_MOD_DELETE of same attribute (accesslog.c:989), it is using the index of the removed value (valx) to find and removed the entry in the linked list, but it's counting from the head of li_oldattrs and not the tail, resulting in the wrong item being removed from the list unless counting from the head or the tail happens find the same item. (Line numbers refer to commit 6c469f07935e351e349bf38fc223dab704c51a76) Handling of oldAccessLogBase appears to have the same problem, and a cursory glance through the source of other overlays reveals a similar pattern, and I'm guessing the same problem. -- You are receiving this mail because: You are on the CC list for the issue.

1 year, 9 months

1
21
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs May 2021