openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

[Issue 9661] New: How to monitor an LDMB file for being pretty full
by openldap-its＠openldap.org 02 Sep '21

02 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9661 Issue ID: 9661 Summary: How to monitor an LDMB file for being pretty full Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- https://ltb-project.org/documentation/nagios-plugins/check_lmdb_usage provides a Nagios plugin, to check how full/free a LMDB database is. It calls mbd_stat -ef, and parses from the output the numbers in the “Max pages:”, “Number of pages used:”, and “Free pages:” lines. With these numbers it calculates “the percent of used pages” or “the percent of free pages” and signals the status with return values 0 -OK, 1 - warning, or 2 - critical . The disadvantage of check_lmdb_usage is, that it requires perl. Do you recommend to monitor the absolute number of free pages, the relative number of free pages, the absolute number of used pager, or the relative number of used pages? Please extend mdb_stat to be suitable for monitoring the fullness of a LMDB directory - accept parameters of for a warning and critical threshold, and a parameter on how to calculate the criterion (A - based on absolute number of free pages, B - relative number of free pages, C - absolute number of used pages, or D - relative number of used pages). -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 8375] paged results control results in full db search?
by openldap-its＠openldap.org 01 Sep '21

01 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=8375 --- Comment #7 from geert.hendrickx(a)telenetgroup.be <geert.hendrickx(a)telenetgroup.be> --- I can reproduce it on any sufficiently large db, both tree-structured or flat, given the right search scope. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8375] paged results control results in full db search?
by openldap-its＠openldap.org 01 Sep '21

01 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=8375 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |needs_review --- Comment #6 from Quanah Gibson-Mount <quanah(a)openldap.org> --- I'll put needs review on it though so we can discuss. ;) -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8375] paged results control results in full db search?
by openldap-its＠openldap.org 01 Sep '21

01 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=8375 --- Comment #5 from Quanah Gibson-Mount <quanah(a)openldap.org> --- (In reply to geert.hendrickx(a)telenetgroup.be from comment #4) > Hi > > I can reproduce exactly the same behaviour with OpenLDAP 2.5.7, on a freshly > slapadd'ed mdb. Target milestone for the fix is 2.7.0, so that's expected. ;) -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8375] paged results control results in full db search?
by openldap-its＠openldap.org 01 Sep '21

01 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=8375 --- Comment #4 from geert.hendrickx(a)telenetgroup.be <geert.hendrickx(a)telenetgroup.be> --- Hi I can reproduce exactly the same behaviour with OpenLDAP 2.5.7, on a freshly slapadd'ed mdb. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9658] New: libldap fails to compile on Hurd: MAXPATHLEN undeclared
by openldap-its＠openldap.org 31 Aug '21

31 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=9658 Issue ID: 9658 Summary: libldap fails to compile on Hurd: MAXPATHLEN undeclared Product: OpenLDAP Version: 2.5.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: ryan(a)openldap.org Target Milestone: --- OpenLDAP 2.5 and later fails to compile on GNU/Hurd: libtool: compile: cc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c request.c -fPIC -DPIC -o .libs/request.o In file included from ldap-int.h:119, from request.c:53: request.c: In function 'ldap_dump_connection': ../../include/ldap_pvt.h:181:25: error: 'MAXPATHLEN' undeclared (first use in this function) 181 | #define LDAP_IPADDRLEN (MAXPATHLEN + sizeof("PATH=")) | ^~~~~~~~~~ request.c:859:17: note: in expansion of macro 'LDAP_IPADDRLEN' 859 | char from[LDAP_IPADDRLEN]; | ^~~~~~~~~~~~~~ ../../include/ldap_pvt.h:181:25: note: each undeclared identifier is reported only once for each function it appears in 181 | #define LDAP_IPADDRLEN (MAXPATHLEN + sizeof("PATH=")) | ^~~~~~~~~~ request.c:859:17: note: in expansion of macro 'LDAP_IPADDRLEN' 859 | char from[LDAP_IPADDRLEN]; | ^~~~~~~~~~~~~~ Makefile:435: recipe for target 'request.lo' failed make[2]: *** [request.lo] Error 1 This is not the same as ITS#9648. I have pulled latest master and the patch for that one does not solve it. GNU/Hurd actually does not have a MAXPATHLEN constant at all; paths are expected to be dynamically allocated. See: https://www.gnu.org/software/hurd/hurd/porting/guidelines.html#PATH_MAX_tt_… This is a low priority issue for me personally. I'm just filing it for tracking. I'm hoping someone from the GNU/Hurd community might be able to work on a patch. -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 6949] OpenLDAP Logging
by openldap-its＠openldap.org 31 Aug '21

31 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=6949 --- Comment #7 from Ondřej Kuzník <ondra(a)mistotebe.net> --- It seems this is limited to slapd main.c so a standalone lloadd keeps the original logging configuration/code/format. Maybe the logging code could move to a separate file so it can be shared between the two. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9657] New: Different access privileges required for SIMPLE BIND (attr: userPassword) and SASL BIND (whole entry)
by openldap-its＠openldap.org 31 Aug '21

31 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=9657 Issue ID: 9657 Summary: Different access privileges required for SIMPLE BIND (attr: userPassword) and SASL BIND (whole entry) Product: OpenLDAP Version: 2.5.6 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- I configure a database with: dn: cn=config objectClass: olcGlobal cn: config olcAuthzRegexp: uid=([^@,]+)(@aegee.org)?(,cn=aegee.org)?,cn=[^,]*,cn=auth uid=$1,ou=persons,o=AEGEE olcSaslSecProps: none ####################################################################### # LMDB database definitions ####################################################################### # dn: olcDatabase=mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: mdb olcDbMaxSize: 10485760 olcSuffix: o=AEGEE olcRootDN: uid=zzz,ou=persons,o=AEGEE olcRootPW: zzz olcDbDirectory: /home/d/ldap/aegee olcDbIndex: objectClass eq olcAccess: to dn.one="ou=persons,o=AEGEE" attrs=userPassword by anonymous auth olcAccess: to dn.one="ou=persons,o=AEGEE" by self read fill the database with /usr/local/bin/ldapadd -x -w zzz -D "uid=zzz;ou=persons;o=AEGEE" -H ldap://localhost <<ABC dn:o=AEGEE o:AEGEE objectClass:organization telephoneNumber:+32 2 246 0320 street:Rue du Noyer / Notelaarsstraat 55 st:Brussels postalAddress:Rue du Noyer / Notelaarsstraat 55, 1000 Brussels, Belgium dn:ou=persons,o=AEGEE objectClass:organizationalUnit description:AEGEE members (persons) with account at https://my.aegee.eu/ dn: uid=lui.veve,ou=persons,o=AEGEE objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson sn: Veve cn: Lui Veve uid: lui.veve employeeNumber: 444 givenName: Lui mail: lui.veve@zzzz userPassword:: dXAx structuralObjectClass: inetOrgPerson ABC Its content is ( slapcat -n1 -F conf/ ) ---- dn: o=AEGEE o: AEGEE objectClass: organization telephoneNumber: +32 2 246 0320 street: Rue du Noyer / Notelaarsstraat 55 st: Brussels postalAddress: Rue du Noyer / Notelaarsstraat 55, 1000 Brussels, Belgium structuralObjectClass: organization entryUUID: 223703d3-812e-405c-b57e-4233b55847c3 creatorsName: uid=zzz,ou=persons,o=AEGEE createTimestamp: 20210830161645Z entryCSN: 20210830161645.797291Z#000000#000#000000 modifiersName: uid=zzz,ou=persons,o=AEGEE modifyTimestamp: 20210830161645Z dn: ou=persons,o=AEGEE objectClass: organizationalUnit description: AEGEE members (persons) with account at https://my.aegee.eu/ structuralObjectClass: organizationalUnit ou: persons entryUUID: 17f8ff72-250b-4cbd-873f-340aaed2f0d9 creatorsName: uid=zzz,ou=persons,o=AEGEE createTimestamp: 20210830161645Z entryCSN: 20210830161645.802430Z#000000#000#000000 modifiersName: uid=zzz,ou=persons,o=AEGEE modifyTimestamp: 20210830161645Z dn: uid=lui.veve,ou=persons,o=AEGEE objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson sn: Veve cn: Lui Veve uid: lui.veve employeeNumber: 444 givenName: Lui mail:: bHVpLnZldmVAenp6eiA= userPassword:: dXAx structuralObjectClass: inetOrgPerson entryUUID: 2e37d641-6865-4a08-87f9-b12653f52d12 creatorsName: uid=zzz,ou=persons,o=AEGEE createTimestamp: 20210830161645Z entryCSN: 20210830161645.806532Z#000000#000#000000 modifiersName: uid=zzz,ou=persons,o=AEGEE modifyTimestamp: 20210830161645Z ---- When I try to authenticate with SIMPLE BIND, OpenLDAP requests only access to the userPassword attribute: ldapwhoami -x -D "uid=lui.veve;ou=persons;o=AEGEE" -v -w up1 -H ldap://localhost/ logs: 612d04f3.27f67994 0x7f50731ac640 <= ldap_dn2bv(uid=lui.veve,ou=persons,o=AEGEE)=0 612d04f3.27f6a83b 0x7f50731ac640 => ldap_dn2bv(272) 612d04f3.27f6cbf9 0x7f50731ac640 <= ldap_dn2bv(uid=lui.veve,ou=persons,o=aegee)=0 612d04f3.27f6e92a 0x7f50731ac640 <<< dnPrettyNormal: <uid=lui.veve,ou=persons,o=AEGEE>, <uid=lui.veve,ou=persons,o=aegee> 612d04f3.27f7035b 0x7f50731ac640 conn=1001 op=0 BIND dn="uid=lui.veve,ou=persons,o=AEGEE" method=128 612d04f3.27f744d5 0x7f50731ac640 do_bind: version=3 dn="uid=lui.veve,ou=persons,o=AEGEE" method=128 612d04f3.27f77c7c 0x7f50731ac640 ==> mdb_bind: dn: uid=lui.veve,ou=persons,o=AEGEE 612d04f3.27f82a00 0x7f50731ac640 mdb_dn2entry("uid=lui.veve,ou=persons,o=aegee") 612d04f3.27f847bd 0x7f50731ac640 => mdb_dn2id("uid=lui.veve,ou=persons,o=aegee") 612d04f3.27f8a6f4 0x7f50731ac640 <= mdb_dn2id: got id=0x3 612d04f3.27f916cf 0x7f50731ac640 => mdb_entry_decode: 612d04f3.27f942bb 0x7f50731ac640 <= mdb_entry_decode 612d04f3.27f96490 0x7f50731ac640 => access_allowed: result not in cache (userPassword) 612d04f3.27f97b35 0x7f50731ac640 => access_allowed: auth access to "uid=lui.veve,ou=persons,o=AEGEE" "userPassword" requested 612d04f3.27f9ab7f 0x7f50731ac640 => dn: [1] ou=persons,o=aegee 612d04f3.27f9ccc7 0x7f50731ac640 => acl_get: [1] matched 612d04f3.27f9ddb2 0x7f50731ac640 => acl_get: [1] attr userPassword 612d04f3.27f9f63f 0x7f50731ac640 => acl_mask: access to entry "uid=lui.veve,ou=persons,o=AEGEE", attr "userPassword" requested 612d04f3.27fa0913 0x7f50731ac640 => acl_mask: to value by "", (=0) 612d04f3.27fa24a1 0x7f50731ac640 <= check a_dn_pat: anonymous 612d04f3.27fa492f 0x7f50731ac640 <= acl_mask: [1] applying auth(=xd) (stop) 612d04f3.27fa5bbd 0x7f50731ac640 <= acl_mask: [1] mask: auth(=xd) 612d04f3.27fa721c 0x7f50731ac640 => slap_access_allowed: auth access granted by auth(=xd) 612d04f3.27fa8306 0x7f50731ac640 => access_allowed: auth access granted by auth(=xd) 612d04f3.27fa9f20 0x7f50731ac640 conn=1001 op=0 BIND dn="uid=lui.veve,ou=persons,o=AEGEE" mech=SIMPLE bind_ssf=0 ssf=0 612d04f3.27fb0385 0x7f50731ac640 do_bind: v3 bind: "uid=lui.veve,ou=persons,o=AEGEE" to "uid=lui.veve,ou=persons,o=AEGEE" When I try to SASL connect, then OpenLDAP requests access to the whole uid=lui.veve,ou=persons,o=AEGEE entry: ldapwhoami -Y LOGIN -U"lui.veve" -v -w up1 -H ldap://localhost/ logs: 612d053d.03ab64b8 0x7f50731ac640 => ldap_bv2dn(uid=lui.veve,ou=persons,o=AEGEE,0) 612d053d.03abb462 0x7f50731ac640 <= ldap_bv2dn(uid=lui.veve,ou=persons,o=AEGEE)=0 612d053d.03abddda 0x7f50731ac640 => ldap_dn2bv(272) 612d053d.03abf0ad 0x7f50731ac640 <= ldap_dn2bv(uid=lui.veve,ou=persons,o=aegee)=0 612d053d.03ac070c 0x7f50731ac640 <<< dnNormalize: <uid=lui.veve,ou=persons,o=aegee> 612d053d.03ac2626 0x7f50731ac640 <==slap_sasl2dn: Converted SASL name to uid=lui.veve,ou=persons,o=aegee 612d053d.03ac68fe 0x7f50731ac640 slap_sasl_getdn: dn:id converted to uid=lui.veve,ou=persons,o=aegee 612d053d.03ac82e9 0x7f50731ac640 SASL Canonicalize [conn=1002]: slapAuthcDN="uid=lui.veve,ou=persons,o=aegee" 612d053d.03acd965 0x7f50731ac640 => mdb_search 612d053d.03ada119 0x7f50731ac640 mdb_dn2entry("uid=lui.veve,ou=persons,o=aegee") 612d053d.03adcf7a 0x7f50731ac640 => mdb_dn2id("uid=lui.veve,ou=persons,o=aegee") 612d053d.03ae10f4 0x7f50731ac640 <= mdb_dn2id: got id=0x3 612d053d.03ae33e0 0x7f50731ac640 => mdb_entry_decode: 612d053d.03ae6313 0x7f50731ac640 <= mdb_entry_decode 612d053d.03ae845b 0x7f50731ac640 => access_allowed: auth access to "uid=lui.veve,ou=persons,o=AEGEE" "entry" requested 612d053d.03aea02f 0x7f50731ac640 => dn: [1] ou=persons,o=aegee 612d053d.03aeba1a 0x7f50731ac640 => acl_get: [1] matched 612d053d.03aed0bf 0x7f50731ac640 => dn: [2] ou=persons,o=aegee 612d053d.03aee392 0x7f50731ac640 => acl_get: [2] matched 612d053d.03aef47c 0x7f50731ac640 => acl_get: [2] attr entry 612d053d.03af0c39 0x7f50731ac640 => acl_mask: access to entry "uid=lui.veve,ou=persons,o=AEGEE", attr "entry" requested 612d053d.03af2f6a 0x7f50731ac640 => acl_mask: to all values by "", (=0) 612d053d.03af45c9 0x7f50731ac640 <= check a_dn_pat: self 612d053d.03af513f 0x7f50731ac640 <= acl_mask: no more <who> clauses, returning =0 (stop) 612d053d.03af626f 0x7f50731ac640 => slap_access_allowed: auth access denied by =0 612d053d.03af7a71 0x7f50731ac640 => access_allowed: no more rules This is inconsistent. SASL bind shall also request only AUTH access to the userPassword, just as SIMPLE BIND does. Moreover, https://www.openldap.org/doc/admin25/access-control.html#Basic%20ACLs does suggest: Generally one should start with some basic ACLs such as: access to attrs=userPassword by self =xw by anonymous auth by * none access to * by self write by users read by * none So the suggestion is to grant "by anonymous auth" access only to attrs=userPassword , before granting any other access. If I change to olcAccess: to dn.one="ou=persons,o=AEGEE" by self read by anonymous auth then both SASL BIND and SIMPLE BIND work. Version 2.5.7-g22d1c5954e8629b. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9655] New: Expose the SNI hostname to olcAccess
by openldap-its＠openldap.org 30 Aug '21

30 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=9655 Issue ID: 9655 Summary: Expose the SNI hostname to olcAccess Product: OpenLDAP Version: 2.5.4 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- Since OpenLDAP now supports SNI, it apparently knows to which Host the client has connected, when the server is reachable under many names. • Expose the negotiated hostname to oclAccess and provide example how to limit the namingContext on the root DSE based on the requested host Rationale: HTTP servers offer the concept of virtual domains, where they serve different content behind the same IP, based on the Host: header. I want to offer public, anonymous LDAP access, but the returned results shall be completely different, and depend on the contacted host. The statements in the <WHO> field peername=<peername>, sockname=<sockname>, domain=<domain>, and sockurl=<sockurl> are evaluated only based on the contacting system (do not depend on the requested domain). (Maybe the “contacting sockurl” can do this, but this is not very clear from the documentation). So they serve similar purpose, but ignore SNI. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9654] New: Allow using both Elliptic curves and RSA certificate
by openldap-its＠openldap.org 30 Aug '21

30 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=9654 Issue ID: 9654 Summary: Allow using both Elliptic curves and RSA certificate Product: OpenLDAP Version: 2.5.4 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- sendmail and Cyrus IMAP allow to set two TLS server certificates -one RSA and EC. When the client supports Elliptic curves, the smaller EC certificate is used. Likewise it accepts two private keys, in case the private key is not included in the certificate file. In sendmail and Cyrus IMAP, two certificates are set in the same directive, separated with comma: define(`confSERVER_CERT', `/etc/zzz/fullchain.pem,/etc/zzz/fullchain_ec.pem') define(`confSERVER_KEY', `/etc/zzz/privkey.pem,/etc/zzz/privkey_ec.pem') In Cyrus IMAP the code dealing with this for OpenSSL is at https://github.com/cyrusimap/cyrus-imapd/blob/master/imap/tls.c#L453 : cf1/kf1 is the fist public/private key, cf2/kf2 are the second. In sendmail the code is in sendmail/tls.c:inittls() - it calls SSL_CTX_use_PrivateKey_file twice - once with keyfile and once with kf2 (keyfile 2). • Extend OpenLDAP to accept several certificates (RSA/EC) - either per permitting several (comma separated) values in olcTLSCertificateFile/olcTLSCertificateKeyFile , or by allowing several occurrences of the property. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

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