openldap-bugs June 2021

openldap-bugs@openldap.org

1 participants
300 discussions

[Issue 5582] Default OpenSSL certs are only used when TLS_CACERT(DIR)
by openldap-its＠openldap.org 03 Jun '21

03 Jun '21

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

1 0

[Issue 5399] LDAP Syntax 1.3.6.1.4.1.1466.115.121.1.58 (Substring Assertion) not listed in subschema subentry
by openldap-its＠openldap.org 03 Jun '21

03 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=5399 --- Comment #8 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Hi Michael, Do you have an example test case/use case you can provide? -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 5500] comments in cn=config entries
by openldap-its＠openldap.org 03 Jun '21

03 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=5500 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |enhancement Target Milestone|2.6.0 |--- -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 5399] LDAP Syntax 1.3.6.1.4.1.1466.115.121.1.58 (Substring Assertion) not listed in subschema subentry
by openldap-its＠openldap.org 03 Jun '21

03 Jun '21

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

1 0

[Issue 5344] Wrong check for bad Modify DN
by openldap-its＠openldap.org 03 Jun '21

03 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=5344 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs(a)openldap.org |ondra(a)mistotebe.net Keywords|OL_2_6_REQ | -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 5335] Update test044 to confirm ACL with "by group.X" clause using a dynamic group functions correctly
by openldap-its＠openldap.org 03 Jun '21

03 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=5335 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.6.0 |--- Keywords|OL_2_6_REQ | -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7853] Improve safety of mdb_env_close
by openldap-its＠openldap.org 03 Jun '21

03 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=7853 --- Comment #5 from Howard Chu <hyc(a)openldap.org> --- (In reply to Howard Chu from comment #4) > (In reply to dw(a)hmmz.org from comment #0) > > Full_Name: David Wilson > > Version: LMDB 0.9.11 > > OS: > > URL: > > https://raw.githubusercontent.com/dw/py-lmdb/master/misc/readers_mrb_env. > > patch > > Submission from: (NULL) (178.238.153.20) > > > > > > Currently if a user (wilfully or accidentally, say, through composition of > > third party libs) opens the same LMDB environment twice within a process, and > > maintains active read transactions at the time one mdb_env_close() is called, > > all reader slots will be deallocated in all environments due to the logic > > around line 4253 that unconditionally clears reader slots based on PID. > > > > I'd like to avoid this in py-lmdb, and seems there are a few alternatives to > > fix it: > > > 4) Modify lock.mdb to include MDB_env* address within the process, and update > > mdb_env_close() to invalidate only readers associated with the environment > > being closed. I dislike using the MDB_env* as an opaque publicly visible > > cookie, but perhaps storing this field might be reused for other things in > > future. > > I was looking at this approach, which initially seems harmless. But > unfortunately it does nothing to address the fact the fcntl lock on the > lock file will still go away on the first env_close() call. If there are > no other processes with the env open, then the next process that opens > the env will re-init the lock file, because it doesn't know about the > existing process. At that point the existing process is hosed anyway. Another possibility here is to detect that there were multiple envs for the same PID, and not close the descriptors in that case. This means intentionally leaking a file descriptor, but keeps the locks intact. Still ugly, but not as bad as inviting corruption. And, this would only happen due to a library misuse, so it would still be a rare situation. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9568] New: ldapsearch command not working with ECC certificates
by openldap-its＠openldap.org 03 Jun '21

03 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=9568 Issue ID: 9568 Summary: ldapsearch command not working with ECC certificates Product: OpenLDAP Version: 2.4.56 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: adisheshsm(a)gmail.com Target Milestone: --- Hi, ldap server is configured with ECC certificate. ldap server certificates are generated using openssl command. mTLS is enabled on ldap server side. for ldap client ldapsearch purpose, we have tried client certs using RSA and ECC. when server is configured with ECC certs, client is not able to connect to server. please let us know if openldap clients work with ECC certificates (prime256v1 curve). we tried below scenarios: both are not working 1. openldap server and client with ECC certificates 2. openldap server with ECC certificate and client with RSA certificate. we are getting below errors. --------client side details----------------- ---------------------------------------- $ cat ~/.ldaprc TLS_CACERT /tmp/ec_cacert.pem TLS_CERT /tmp/rsa_client.pem TLS_KEY /tmp/rsa_client.key TLS_REQCERT never TLS_PROTOCOL_MIN 3.2 -------------------------------------------------- ## ldapsearch command is failing (with -Z and -ZZ) $ ldapsearch -x -h 10.21.21.2 -p 389 -D "cn=admin" -w 'admin1' -b "uid=001,dc=test1" -Z -d 1 ldap_create ldap_url_parse_ext(ldap://10.21.21.2:389) ldap_extended_operation_s ldap_extended_operation ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP 10.21.21.2:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 10.21.21.2:389 ldap_pvt_connect: fd: 3 tm: -1 async: 0 attempting to connect: connect success ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({) ber: ber_flush2: 31 bytes to sd 3 ldap_result ld 0x7f94593a6210 msgid 1 wait4msg ld 0x7f94593a6210 msgid 1 (infinite timeout) wait4msg continue ld 0x7f94593a6210 msgid 1 all 1 ** ld 0x7f94593a6210 Connections: * host: 10.21.21.2 port: 389(default) refcnt: 2 status: Connected last used: Thu Jun 3 11:28:26 2021 ** ld 0x7f94593a6210 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x7f94593a6210 request count 1 (abandoned 0) ** ld 0x7f94593a6210 Response Queue: Empty ld 0x7f94593a6210 response count 0 ldap_chkResponseList ld 0x7f94593a6210 msgid 1 all 1 ldap_chkResponseList returns ld 0x7f94593a6210 NULL ldap_int_select read1msg: ld 0x7f94593a6210 msgid 1 all 1 ber_get_next ber_get_next: tag 0x30 len 38 contents: read1msg: ld 0x7f94593a6210 msgid 1 message type extended-result ber_scanf fmt ({eAA) ber: read1msg: ld 0x7f94593a6210 0 new referrals read1msg: mark request completed, ld 0x7f94593a6210 msgid 1 request done: ld 0x7f94593a6210 msgid 1 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_parse_extended_result ber_scanf fmt ({eAA) ber: ber_scanf fmt (a) ber: ber_scanf fmt (O) ber: ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (x) ber: ber_scanf fmt (x) ber: ber_scanf fmt (}) ber: ldap_msgfree TLS: certdb config: configDir='/etc/openldap/certs' tokenDescription='ldap(0)' certPrefix='' keyPrefix='' flags=readOnly TLS: using moznss security dir /etc/openldap/certs prefix . TLS: loaded CA certificate file /tmp/ec_cacert.pem. TLS: error: the certificate '/tmp/rsa_client.pem' could not be found in the database - error -8174:security library: bad database.. TLS: certificate '/tmp/rsa_client.pem' successfully loaded from PEM file. TLS: no unlocked certificate for certificate 'CN=ldapclient,OU=test,O=example,L=Banaglore,ST=Karnataka,C=IN'. TLS: certificate [CN=ldapclient,OU=test,O=example,L=Banaglore,ST=Karnataka,C=IN] is valid TLS: error: tlsm_PR_Recv returned 0 - error 21:Is a directory TLS: error: connect - force handshake failure: errno 21 - moznss error -5938 TLS: can't connect: TLS error -5938:Encountered end of file. ldap_err2string ldap_start_tls: Connect error (-11) additional info: TLS error -5938:Encountered end of file ldap_sasl_bind ldap_send_initial_request ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({i) ber: ber_flush2: 30 bytes to sd 3 ldap_result ld 0x7f94593a6210 msgid 2 wait4msg ld 0x7f94593a6210 msgid 2 (infinite timeout) wait4msg continue ld 0x7f94593a6210 msgid 2 all 1 ** ld 0x7f94593a6210 Connections: * host: 10.21.21.2 port: 389 (default) refcnt: 2 status: Connected last used: Thu Jun 3 11:28:26 2021 ** ld 0x7f94593a6210 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ld 0x7f94593a6210 request count 1 (abandoned 0) ** ld 0x7f94593a6210 Response Queue: Empty ld 0x7f94593a6210 response count 0 ldap_chkResponseList ld 0x7f94593a6210 msgid 2 all 1 ldap_chkResponseList returns ld 0x7f94593a6210 NULL ldap_int_select read1msg: ld 0x7f94593a6210 msgid 2 all 1 ber_get_next ldap_err2string ldap_result: Can't contact LDAP server (-1) ldap_free_request (origid 2, msgid 2) ldap_free_connection 1 1 ldap_free_connection: actually freed $ Thanks and regards, Adishesh -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9566] New: OpenLDAP Proxy crashes when idassertauthzfrom is set to dn:*
by openldap-its＠openldap.org 03 Jun '21

03 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=9566 Issue ID: 9566 Summary: OpenLDAP Proxy crashes when idassertauthzfrom is set to dn:* Product: OpenLDAP Version: 2.4.56 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: nevillem(a)issquaredinc.com Target Milestone: --- Set olcDbIDAssertAuthzFrom to {0}dn:* Set olcDbIDAssertBind when flag is set to prescriptive or non-prescriptive Stop slapd Start slapd - It does not start, errors out. It works when olcDbIDAssertBind has flags set to flags=proxy-authz-non-critical -- You are receiving this mail because: You are on the CC list for the issue.

1 1

[Issue 8392] Opening multiple databases from the same process
by openldap-its＠openldap.org 02 Jun '21

02 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=8392 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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs June 2021