openldap-bugs November 2020

openldap-bugs@openldap.org

1 participants
96 discussions

[Issue 9397] New: LMDB: A second process opening a file with MDB_WRITEMAP can cause the first to SIGBUS
by openldap-its＠openldap.org 12 Dec '20

12 Dec '20

https://bugs.openldap.org/show_bug.cgi?id=9397 Issue ID: 9397 Summary: LMDB: A second process opening a file with MDB_WRITEMAP can cause the first to SIGBUS Product: LMDB Version: 0.9.26 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: github(a)nicwatson.org Target Milestone: --- Created attachment 780 --> https://bugs.openldap.org/attachment.cgi?id=780&action=edit Full reproduction of SIGBUS MDB_WRITEMAP issue (works on Linux only) The fundamental problem is that a ftruncate() on Linux that makes a file smaller will cause accesses past the new end of the file to SIGBUS (see the mmap man page). The sequence that causes a SIGBUS involves two processes. 1. The first process opens a new LMDB file with MDB_WRITEMAP. 2. The second process opens the same LMDB file with MDB_WRITEMAP and with an explicit map_size smaller than the first process's map size. * This causes an ftruncate that makes the underlying file *smaller*. 3. (Optional) The second process closes the environment and exits. 4. The first process opens a write transaction and writes a bunch of data. 5. The first process commits the transaction. This causes a memory read from the mapped memory that's now past the end of the file. On Linux, this triggers a SIGBUS. Attached is code that fully reproduces the problem on Linux. The most straightforward solution is to allow ftruncate to *reduce* the file size if it is the only reader. Another possibility is check the file size and ftruncate if necessary every time a write transaction is opened. A third possibility is to catch the SIGBUS signal. Repro note: I used clone() to create the subprocess to most straightforwardly demonstrate that the problem is not due to inherited file descriptors. The problem still manifests when the processes are completely independent. -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 6036] Crash: UUIDNormalize doesn't clear output on error
by openldap-its＠openldap.org 05 Dec '20

05 Dec '20

https://bugs.openldap.org/show_bug.cgi?id=6036 --- Comment #5 from amez365 <fieldengineer59(a)yahoo.com> --- Infrastructure Engineer https://www.fieldengineer.com/skills/what-is-an-infrastructure-engineer Infrastructure Engineer's roles include being responsible for designing, building, implementing and maintaining the IT infrastructure using the latest technology. An IT infrastructure engineer ensures that all IT systems that support businesses of any size operate efficiently. https://www.fieldengineer.com/skills/what-is-an-infrastructure-engineer -- You are receiving this mail because: You are on the CC list for the issue.

4 3

[Issue 9401] New: Fix ldap_install_tls function name
by openldap-its＠openldap.org 30 Nov '20

30 Nov '20

https://bugs.openldap.org/show_bug.cgi?id=9401 Issue ID: 9401 Summary: Fix ldap_install_tls function name 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: --- The ldap_install_tls function is really an internal only method for slapd. It should be renamed accordingly to ldap_int_install_tls to reflect this fact, and the documentation updated accordingly. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 8528] Incorrect results on replace op for olcAccess
by openldap-its＠openldap.org 27 Nov '20

27 Nov '20

https://bugs.openldap.org/show_bug.cgi?id=8528 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #7 from Howard Chu <hyc(a)openldap.org> --- (In reply to Quanah Gibson-Mount from comment #1) > --On Friday, November 04, 2016 12:41 AM +0000 openldap-its(a)OpenLDAP.org > wrote: > > Here's the full text, since the web form apparently ate it: > > When doing a full replace on all values for olcAccess, things work > incorrectly if the values provided are not in numeric sorted order. This > is problematic when using tools like ldapvi who do alphabetic sort. It is > trivial to reproduce the problem using the following example LDIFs: > > cat > replace_ordered.ldif <<EOF > dn: olcDatabase={1}mdb,cn=config > changetype: modify > replace: olcAccess > olcAccess: {0}to dn.exact="cn=0" by * none > olcAccess: {1}to dn.exact="cn=1" by * none > olcAccess: {2}to dn.exact="cn=2" by * none > olcAccess: {3}to dn.exact="cn=3" by * none > olcAccess: {4}to dn.exact="cn=4" by * none > olcAccess: {5}to dn.exact="cn=5" by * none > olcAccess: {6}to dn.exact="cn=6" by * none > olcAccess: {7}to dn.exact="cn=7" by * none > - > EOF > > cat > replace_ordered_mixup.ldif <<EOF > dn: olcDatabase={1}mdb,cn=config > changetype: modify > replace: olcAccess > olcAccess: {7}to dn.exact="cn=7" by * none > olcAccess: {1}to dn.exact="cn=1" by * none > olcAccess: {4}to dn.exact="cn=4" by * none > olcAccess: {3}to dn.exact="cn=3" by * none > olcAccess: {5}to dn.exact="cn=5" by * none > olcAccess: {0}to dn.exact="cn=0" by * none > olcAccess: {6}to dn.exact="cn=6" by * none > olcAccess: {2}to dn.exact="cn=2" by * none > - > EOF > > With the initial config as: > > olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * > none > olcAccess: {1}to attrs=shadowLastChange by self write by * read > olcAccess: {2}to * by * read > > When the ordered version is done, the correct result occurs: > > olcAccess: {0}to dn.exact="cn=0" by * none > olcAccess: {1}to dn.exact="cn=1" by * none > olcAccess: {2}to dn.exact="cn=2" by * none > olcAccess: {3}to dn.exact="cn=3" by * none > olcAccess: {4}to dn.exact="cn=4" by * none > olcAccess: {5}to dn.exact="cn=5" by * none > olcAccess: {6}to dn.exact="cn=6" by * none > olcAccess: {7}to dn.exact="cn=7" by * none > > However, when the unordered replaced is done, an incorrect result occurs: > > olcAccess: {0}to dn.exact="cn=0" by * none > olcAccess: {1}to dn.exact="cn=7" by * none > olcAccess: {2}to dn.exact="cn=2" by * none > olcAccess: {3}to dn.exact="cn=1" by * none > olcAccess: {4}to dn.exact="cn=4" by * none > olcAccess: {5}to dn.exact="cn=3" by * none > olcAccess: {6}to dn.exact="cn=5" by * none > olcAccess: {7}to dn.exact="cn=6" by * none > > Since we are doing a replace of all values, it should not be trying to > reweight the operation. Instead, the values should just be numeric sorted > and then written out accordingly, so one ends up with the same result as in > the ordered case. This ITS is invalid. The frontend is not trying to reweight the operation, but you're giving it invalid input. It processes each value in the order it was given. You put {7} first but at that point in time, there aren't 7 values in the attribute, so it goes "at the end". The 2nd input is {1}, which gets put into the 2nd slot, so you have {7}, {1}. The 3rd input is {4} but there are only 2 values, so it goes at the end in the 3rd slot. The 4th input is {3} so it gets inserted into the 3rd slot and pushes the previous value in the 3rd slot into the 4th slot. The 5th input is {5} so it goes at the end. The 6th input is {0} so it gets inserted into the 1st slot and pushes everything else out by 1. The 7th input is {6} so it goes at the end. The 8th input is {2} so it gets inserted in the 3rd slot and pushes everything else out by 1. Closing this ITS. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9405] New: Link to Administrator's Guide is 404
by openldap-its＠openldap.org 23 Nov '20

23 Nov '20

https://bugs.openldap.org/show_bug.cgi?id=9405 Issue ID: 9405 Summary: Link to Administrator's Guide is 404 Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: p.boven(a)xs4all.nl Target Milestone: --- On the 'software' page (https://www.openldap.org/software/), the link to the "Administrator's Guide" page currently gives a 404 error. The admin page link points to https://www.openldap.org/doc/admin/, but this should apparently be https://www.openldap.org/doc/admin24/ -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9402] New: Add support for LDAP_MATCHING_RULE_IN_CHAIN (1.2.840.113556.1.4.1941)
by openldap-its＠openldap.org 23 Nov '20

23 Nov '20

https://bugs.openldap.org/show_bug.cgi?id=9402 Issue ID: 9402 Summary: Add support for LDAP_MATCHING_RULE_IN_CHAIN (1.2.840.113556.1.4.1941) Product: OpenLDAP Version: 2.4.56 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: vdanjean.ml(a)free.fr Target Milestone: --- Hi, The memberof overlay add support for memberOf attributes. But, when using nested groups, user group membership must be handled on each ldap client. The current implementation allows one to only retrieve direct group ownership. Nested group membership must be done by client recursive lookup. Microsoft Active Directory provides a way to do the recursive lookup at server side: https://ldapwiki.com/wiki/LDAP_MATCHING_RULE_IN_CHAIN It would be really useful if openldap (slapd) was also able to do the same. Regards, Vincent PS: I set the component to overlays in this bugs report, but I'm not sure it should be implemented into the overlays memberof itself. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9399] New: OpenLDAP build fails due to lloadd
by openldap-its＠openldap.org 20 Nov '20

20 Nov '20

https://bugs.openldap.org/show_bug.cgi?id=9399 Issue ID: 9399 Summary: OpenLDAP build fails due to lloadd Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: tero.saarni(a)est.tech Target Milestone: --- Cloning current git head and running build steps according to INSTALL fails: ./configure make depends The error is following: Entering subdirectory lloadd make[2]: Entering directory '/home/tsaarni/work/openldap/servers/lloadd' make[2]: *** No rule to make target 'depend'. Stop. make[2]: Leaving directory '/home/tsaarni/work/openldap/servers/lloadd' make[1]: *** [Makefile:333: depend-common] Error 1 make[1]: Leaving directory '/home/tsaarni/work/openldap/servers' make: *** [Makefile:354: depend-common] Error 1 The reason is that "autoreconf" results have not been committed to git. Running autoreconf && ./configure && make depend && make works. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 8839] never use md5 and/or sha1, use sha-3 512 and/or blake3, file signing
by openldap-its＠openldap.org 17 Nov '20

17 Nov '20

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

1 0

[Issue 8839] never use md5 and/or sha1, use sha-3 512 and/or blake3, file signing
by openldap-its＠openldap.org 17 Nov '20

17 Nov '20

https://bugs.openldap.org/show_bug.cgi?id=8839 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Quanah Gibson-Mount <quanah(a)openldap.org> --- generation of sha3-512 is now in for 2.5 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8747] LDAP load balancer daemon (lloadd)
by openldap-its＠openldap.org 17 Nov '20

17 Nov '20

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

1 0

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs November 2020