openldap-bugs January 2023

openldap-bugs@openldap.org

1 participants
141 discussions

[Issue 9863] New: lastbind configuration fails to honor chaining configuration
by openldap-its＠openldap.org 09 Oct '23

09 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=9863 Issue ID: 9863 Summary: lastbind configuration fails to honor chaining configuration Product: OpenLDAP Version: 2.6.2 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: --- In an environment where consumers are configured to chain writes up to the providers, lastbind configuration fails to honor this which is generally what one would expect. This causes mismatches between the providers and consumers in regards to the database state. Additionally it introduces random serverIDs into the database. In my case, the providers have serverIDs 10, 20, 30 configured but the consumer is generating serverID 1 for the entryCSN. Expectation: consumer does not generate *any* entryCSN value and instead forwards the write op to the provider. Log from consumer: slap_get_csn: conn=1069 op=0 generated new csn=20220610180137.644625Z#000000#001#000000 manage=1 -- You are receiving this mail because: You are on the CC list for the issue.

1 12

[Issue 9735] New: [PATCH] try hard to find free space if database cannot grow
by openldap-its＠openldap.org 30 Sep '23

30 Sep '23

https://bugs.openldap.org/show_bug.cgi?id=9735 Issue ID: 9735 Summary: [PATCH] try hard to find free space if database cannot grow Product: LMDB Version: 0.9.24 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: libor.peltan(a)nic.cz Target Milestone: --- Created attachment 851 --> https://bugs.openldap.org/attachment.cgi?id=851&action=edit Patch fixing the issue "try hard to find free space if database cannot grow" Note: - the issue is the same in version 0.9.70 (git) Situation: - the database had already grown to its limit (mapsize) in the past - overflow pages are used heavily as stored values are usually several pages long - free space got fragmented Problem: - attempt to insert new value results in MDB_MAP_FULL despite there is free space available Cause: there is a heursitic in mdb_page_alloc() that gives up searching for free space chunk if this would take too much time. This is useful when the database can still grow, as it balances performance with space usage. However, if the database can no longer grow, it prevents inserting new values. Solution: detect early on in mdb_page_alloc() if the database can grow, and if not, let it try hard to search for free space. Patch: attached -- You are receiving this mail because: You are on the CC list for the issue.

1 13

[Issue 9471] New: Add RBAC overlay to core
by openldap-its＠openldap.org 26 Sep '23

26 Sep '23

https://bugs.openldap.org/show_bug.cgi?id=9471 Issue ID: 9471 Summary: Add RBAC overlay to core Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Symas will contribute its RBAC overlay to core The slapo-rbac overlay is an implementation of the ANSI INCITS 359 Role-Based Access Control (RBAC) Core. When instantiated, it intercepts, decodes and enforces specific RBAC policies per the Apache Fortress RBAC data formats. The overlay provides a set of extended operations. They include session create/delete, checkAccess, addActiveRole, dropActiveRole and sessionRoles. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9472] New: Add datamorph overlay to core
by openldap-its＠openldap.org 26 Sep '23

26 Sep '23

https://bugs.openldap.org/show_bug.cgi?id=9472 Issue ID: 9472 Summary: Add datamorph overlay to core Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Symas will contribute its datamorph overlay to core The datamorph overlay to slapd allows attributes with a few predefined values to be saved more space-efficiently as well as signed or unsigned integer attributes. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9473] New: Add variant overlay to core
by openldap-its＠openldap.org 26 Sep '23

26 Sep '23

https://bugs.openldap.org/show_bug.cgi?id=9473 Issue ID: 9473 Summary: Add variant overlay to core Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Symas will contribute its variant overlay to OpenLDAP core The variant overlay to slapd allows attributes/values to be shared between several entries. In some ways this is similar to slapo-collect with the exception that the source and target attributes can be different. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9989] New: «make clean» shall not delete libraries/libldap/ldap.pc and libraries/liblber/lber.pc
by openldap-its＠openldap.org 10 Jul '23

10 Jul '23

https://bugs.openldap.org/show_bug.cgi?id=9989 Issue ID: 9989 Summary: «make clean» shall not delete libraries/libldap/ldap.pc and libraries/liblber/lber.pc Product: OpenLDAP Version: 2.6.3 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- «./configure» and «./config.status» do create ./libraries/libldap/ldap.pc, ./libraries/liblber/lber.pc, while «make clean» deletes both .pc files. «make install» fails, if ./libraries/libldap/ldap.pc or ./libraries/liblber/lber.pc are missing. «./configure && make clean && make depend && make install» is a valid workflow for many other (autoconf/automake based) projects. ./libraries/libldap/ldap.pc and ./libraries/liblber/lber.pc shall be deleted by «make distclean», and kept by «make clean». See also https://www.gnu.org/prep/standards/html_node/Standard-Targets.html for the idea behind «make clean» vs «make distclean». -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 9990] New: Part of the ITS#8698 fix breaks exop overlays that set a callback
by openldap-its＠openldap.org 10 Jul '23

10 Jul '23

https://bugs.openldap.org/show_bug.cgi?id=9990 Issue ID: 9990 Summary: Part of the ITS#8698 fix breaks exop overlays that set a callback Product: OpenLDAP Version: 2.5.13 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: subbarao(a)computer.org Target Milestone: --- We have a password exop overlay that sets up a callback, which has stopped working when upgrading to 2.5.13. and I tracked it down to a change to servers/slapd/passwd.c implemented as part of the fix for ITS#8698: https://git.openldap.org/openldap/openldap/-/merge_requests/304/diffs?commi… It appears that the intent of this change was to loop through the o_callback list and only remove the cb callback created in this section of the code. But that isn't necessary because the cb callback never gets added to the original list. With this change, line 295 clobbers the original o_callback list which never gets restored -- that's why our exop overlay stopped working. Fortunately, the fix is very simple -- just revert this part of the change. The original code already saved/restored the o_callback list properly. When I reverted this part of the change, our exop overlay resumed working, and the rest of the ITS#8698 functionality (messages from the pwdCheckModule module being returned to the user) also worked as expected. -- You are receiving this mail because: You are on the CC list for the issue.

1 13

[Issue 9953] New: Push replication issue for the pwdHistory attribute
by openldap-its＠openldap.org 10 Jul '23

10 Jul '23

https://bugs.openldap.org/show_bug.cgi?id=9953 Issue ID: 9953 Summary: Push replication issue for the pwdHistory attribute Product: OpenLDAP Version: 2.4.57 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: dh(a)dotlan.net Target Milestone: --- Hello, I'm using a master ldap instance with a push replication instance to external slaves using the ldap backend on Debian 11 (2.4.57) and I came across some replication issues that forces me to drop the slave dbs and do a manually fullsync everything this error occurs. The problem =========== I know that replication and maintaining a password policy is a complicated task, especially since the ppolicy overlay must be loaded and active in every instance (master, push instance, slave). This problem leads to interesting challanges. First, I encountered a problem where pwdChangedTime would be duplicate because the ppolicy overlay of the push instance and the back_ldap/slave instance would like to set it (which leads to a duplicate attribute error). To fix problem I backported the patch [1] to my local version of the slapd packages. After this problem was fixed, I've encountered the next problematic attribute: "pwdHistory". I've play around with some syncrepl settings, but in the end, it seems to be a similar issue. It looks likes the pwdHistory attribute is not yet present on the slave and both instances (push and slave) try to add the pwdHistory Attributes which leads to a problem where both entries collied (pwdHistory: value #0 already exists). For whatever reason pwdHistory doesn't show up as modified field on the slave in the MOD request. But anyways. Something seems to be wrong, and it could a similar replication issue compared with pwdChangedTime I've lookup into the change history of the ppolicy.c file in the 2.5 and 2.6 branch but couldn't find a newer commit that would address this issue. Does anyone has encountered a similar issue? I've not played around with the 2.5 or 2.6 version, but looking at the code, I've either not seen a fix or the problem might still exist, hopefully I am wrong. Any suggestions? -- best regards Daniel Hoffend [1] https://github.com/openldap/openldap/commit/7a34f46d1cabe8e80937d5167b62152… Setup ===== Host Master - Debian 11 slapd 2.4.57+dfsg-3 - slapd master instance with cn=config - push replikation instance with simple config (syncrepl from localhost, write to backend ldap) Host Slave - Debian 11 slapd 2.4.57+dfsg-3 - Readonly slave On all 3 instances ppolicy is enabled otherwise the operational attributes would be not known/available and sync of locked accounts or per account selected password policy assignment wouldn't work. PUSH Replication Instance ========================= database ldap [...] overlay ppolicy ppolicy_default "cn=default,ou=policies,dc=example,dc=org" syncrepl rid=__RID__ provider=ldap://localhost:389/ binddn="cn=replication,ou=system,dc=example,dc=org" bindmethod=simple credentials="secret" searchbase="dc=example,dc=org" type=refreshAndPersist schemachecking=off retry="5 12 60 +" attrs="*,memberOf,pwdPolicySubentry,pwdChangedTime,pwdAccountLockedTime,pwdHistory,creatorsName,createTimestamp,modifiersName,modifyTimestamp" --- Nov 3 00:00:45 ldapmaster slapd[2308611]: syncrepl_message_to_entry: rid=016 DN: uid=user1,ou=accounts,dc=example,dc=org, UUID: db720f56-df0d-103c-8635-9543ccd6e97d Nov 3 00:00:45 ldapmaster slapd[2308611]: syncrepl_entry: rid=016 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) csn=(none) tid a0a89700 Nov 3 00:00:45 ldapmaster slapd[2308611]: syncrepl_entry: rid=016 be_search (0) Nov 3 00:00:45 ldapmaster slapd[2308611]: syncrepl_entry: rid=016 uid=user1,ou=accounts,dc=example,dc=org Nov 3 00:00:45 ldapmaster slapd[2308611]: syncrepl_null_callback : error code 0x14 Nov 3 00:00:45 ldapmaster slapd[2308611]: syncrepl_entry: rid=016 be_modify uid=user1,ou=accounts,dc=example,dc=org (20) Nov 3 00:00:45 ldapmaster slapd[2308611]: syncrepl_entry: rid=016 be_modify failed (20) Nov 3 00:00:45 ldapmaster slapd[2308611]: do_syncrepl: rid=016 rc 20 retrying SLAVE LDAP Server ================= database mdb [...] overlay ppolicy ppolicy_default "cn=default,ou=policies,dc=example,dc=org" --- Nov 3 00:00:45 ldapslave slapd[2221506]: conn=176499 op=59513 SRCH base="uid=user1,ou=accounts,dc=example,dc=org" scope=0 deref=0 filter="(objectClass=*)" Nov 3 00:00:45 ldapslave slapd[2221506]: conn=176499 op=59513 SEARCH RESULT tag=101 err=0 nentries=1 text= Nov 3 00:00:45 ldapslave slapd[2221506]: conn=176500 op=59513 MOD dn="uid=user1,ou=accounts,dc=example,dc=org" Nov 3 00:00:45 ldapslave slapd[2221506]: conn=176500 op=59513 MOD attr=structuralObjectClass creatorsName createTimestamp userPassword pwdChangedTime memberOf entryCSN modifiersName modifyTimestamp Nov 3 00:00:45 ldapslave slapd[2221506]: conn=176500 op=59513 RESULT tag=103 err=20 text=modify/add: pwdHistory: value #0 already exists -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9736] New: pwrite bug in OSX breaking LMDB promise about the maximum value size
by openldap-its＠openldap.org 22 May '23

22 May '23

https://bugs.openldap.org/show_bug.cgi?id=9736 Issue ID: 9736 Summary: pwrite bug in OSX breaking LMDB promise about the maximum value size Product: LMDB Version: unspecified Hardware: All OS: Mac OS Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: renault.cle(a)gmail.com Target Milestone: --- Hi, I was working with LMDB and found an issue when trying to write a value of approximately 3.3GiB in the database, I dive into the LMDB source code of the mdb_put method using the lldb debugger and found out that it was not related to an issue in LMDB itself but rather a bug in the pwrite function of the Mac OS libc implementation. The pwrite function is given four parameters, the file descriptor, the buffer, the count of bytes to write from the buffer and, the offset of where to write it in the file. On Mac OS the count of bytes is a size_t that must be a 64bits unsigned integer but when you call pwrite with a number bigger or equal to 2^31 it returns an error 22 (invalid argument). LMDB was returning a 22 error from the mdb_put call and not an EINVAL because the error was cause by an internal issue and not something catchable by LMDB. I am not sure about what we can do, can we implement this single pwrite [1] as multiple pwrite with counts smaller than 2^31 in a loop, just for Mac OS? Like for Windows where we do specific things for this operating system too? I also found this issue on the RocksDB repository [2] about a similar problem they have with pwrite and write on Mac OS it seems. I understand that this is not a real promise that LMDB is specifying but rather an "in theory" rule [3]. Thank you for your time, kero [1]: https://github.com/LMDB/lmdb/blob/01b1b7dc204abdf3849536979205dc9e3a0e3ece/… [2]: https://github.com/facebook/rocksdb/issues/5169 [3]: http://www.lmdb.tech/doc/group__mdb.html#structMDB__val -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9436] New: OpenSSL 3.0: libldap uses depreciated functions
by openldap-its＠openldap.org 27 Apr '23

27 Apr '23

https://bugs.openldap.org/show_bug.cgi?id=9436 Issue ID: 9436 Summary: OpenSSL 3.0: libldap uses depreciated functions Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- OpenLDAP master fails to build against OpenSSL 3.0 alpha when "no-deprecated" is specified. Currently hitting these errors: ./.libs/libldap.so: undefined reference to `SSL_get_peer_certificate' ./.libs/libldap.so: undefined reference to `PEM_read_bio_DHparams' ./.libs/libldap.so: undefined reference to `ERR_get_error_line' ./.libs/libldap.so: undefined reference to `DH_free' ./.libs/libldap.so: undefined reference to `SSL_CTX_set_tmp_dh' Notes: SSL_get_peer_certificate is SSL_get1_peer_certificate in 3.0.0 SSL_CTX_set_tmp_dh should be replaced as follows: # define SSL_CTX_set_tmp_dh(ctx,dh) \ SSL_CTX_ctrl(ctx,SSL_CTRL_SET_TMP_DH,0,(char *)(dh)) Have to dig deeper for: PEM_read_bio_DHparams ERR_get_error_line DH_free -- You are receiving this mail because: You are on the CC list for the issue.

1 18

← Newer
1
...
4
5
6
7
8
9
10
...
15
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 January 2023