https://bugs.openldap.org/show_bug.cgi?id=8724
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|IN_PROGRESS |RESOLVED
--- Comment #13 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
Commits:
• 932d18fd
by Quanah Gibson-Mount at 2021-03-04T21:44:38+00:00
ITS#8724 - Note that paged results is stripped
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8871
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|WONTFIX |INVALID
--- Comment #3 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
The use case here is invalid, and the code prior to ITS#6672 was broken. There
is nothing here to be fixed.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=7990
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|IN_PROGRESS |RESOLVED
Resolution|--- |FIXED
--- Comment #8 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
Commits:
• 76142803
by Quanah Gibson-Mount at 2021-03-04T20:43:08+00:00
ITS#7990 - add section on hashing cleartext passwords
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8871
--- Comment #2 from hsuenju_ko(a)stratus.com <hsuenju_ko(a)stratus.com> ---
This used to work before #6672. The code used to unlock the ld_conn_mutex
before the select call.
what if one thread is doing ldap_result with indefinite wait while other thread
is doing something, not necessary cancel, which also requires holding the
ld_conn_mutex lock? Are you saying no other thread is allowed to do anything
requiring the same ld_conn_mutex?
If I can not use the same connection, how do I do multiple connections? Can I
cancel operations from different connection?
Thanks for any feedback!
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9477
Issue ID: 9477
Summary: slapd on master branch segfaults at first connection
establishment with an LDAP client
Product: OpenLDAP
Version: 2.5
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: david.coutadeur(a)gmail.com
Target Milestone: ---
Everything is in the title:
slapd on master branch segfaults at first connection establishment with an LDAP
client
slapd-2.5.X-Devel
Compilation options:
./configure --prefix=/usr/local/openldap --libdir=/usr/local/openldap/lib64
--enable-overlays --enable-modules --enable-dynamic=yes --with-tls=openssl
--enable-debug --with-cyrus-sasl --enable-spasswd --enable-ppolicy
--enable-crypt --enable-ldap -enable-slapi --enable-meta --enable-sock
--enable-wrappers --enable-rlookups
using default slapd.conf file:
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /usr/local/openldap/etc/openldap/schema/core.schema
# Define global ACLs to disable default read access.
# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral ldap://root.openldap.org
pidfile /usr/local/openldap/var/run/slapd.pid
argsfile /usr/local/openldap/var/run/slapd.args
# Load dynamic backend modules:
# modulepath /usr/local/openldap/libexec/openldap
# moduleload back_mdb.la
# moduleload back_ldap.la
# Sample security restrictions
# Require integrity protection (prevent hijacking)
# Require 112-bit (3DES or better) encryption for updates
# Require 63-bit encryption for simple bind
# security ssf=1 update_ssf=112 simple_bind=64
# Sample access control policy:
# Root DSE: allow anyone to read it
# Subschema (sub)entry DSE: allow anyone to read it
# Other DSEs:
# Allow self write access
# Allow authenticated users read access
# Allow anonymous users to authenticate
# Directives needed to implement policy:
# access to dn.base="" by * read
# access to dn.base="cn=Subschema" by * read
# access to *
# by self write
# by users read
# by anonymous auth
#
# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn. (e.g., "access to * by * read")
#
# rootdn can always read and write EVERYTHING!
#######################################################################
# MDB database definitions
#######################################################################
database mdb
maxsize 1073741824
suffix "dc=my-domain,dc=com"
rootdn "cn=Manager,dc=my-domain,dc=com"
# Cleartext passwords, especially for the rootdn, should
# be avoid. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
rootpw secret
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory /usr/local/openldap/var/openldap-data
# Indices to maintain
index objectClass eq
For information, I also converted this configuration into cn=config with the
same result.
some commands after installation:
mkdir /usr/local/openldap/var/openldap-data
chown -R ldap:ldap /usr/local/openldap
Launch command:
/usr/local/openldap/libexec/slapd -h 'ldap://*:389 ldaps://*:636' -f
/usr/local/openldap/etc/openldap/slapd.conf -u ldap -g ldap -d -1
Establish connection with any client with manager credential on 389 port.
Console output:
6036a1a3 daemon: activity on 1 descriptor
6036a1a3 daemon: activity on:
6036a1a3 slap_listener_activate(7):
6036a1a3 daemon: epoll: listen=7 busy
6036a1a3 daemon: epoll: listen=8 active_threads=0 tvp=NULL
6036a1a3 daemon: epoll: listen=9 active_threads=0 tvp=NULL
6036a1a3 daemon: epoll: listen=10 active_threads=0 tvp=NULL
6036a1a3 >>> slap_listener(ldap://*:389)
6036a1a3 daemon: accept() = 14
6036a1a3 daemon: activity on 1 descriptor
6036a1a3 daemon: activity on:
6036a1a3 daemon: epoll: listen=7 active_threads=0 tvp=NULL
6036a1a3 daemon: epoll: listen=8 active_threads=0 tvp=NULL
6036a1a3 daemon: epoll: listen=9 active_threads=0 tvp=NULL
6036a1a3 daemon: epoll: listen=10 active_threads=0 tvp=NULL
6036a1a3 daemon: listen=7, new connection on 14
Erreur de segmentation
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9433
Issue ID: 9433
Summary: ldapsearch -Z fails to continue when StartTLS fails
Product: OpenLDAP
Version: 2.4.56
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: simon.pichugin(a)gmail.com
Target Milestone: ---
Created attachment 783
--> https://bugs.openldap.org/attachment.cgi?id=783&action=edit
ldapsearch debug log
When -Z is passed to an OpenLDAP utility, it will try to establish a TLS
connection with StartTLS, and in case it fails to do so it should continue
without the TLS layer.
OpenLDAP version:
openldap-2.4.56-4.fc34.x86_64 (but it also doesn't work on older versions too)
How reproducible:
Always
Steps to Reproduce:
1. Run `ldapsearch ...' against a server and see successful operation result.
2. Run `ldapsearch -Z ...' against a server whose certificate is not trusted
(e.g. a hostname mismatch) and observe it fails to connect as in point 1.
Actual results:
~~~
ldap_start_tls: Connect error (-11)
additional info: TLS: hostname does not match CN in peer certificate
# and it hangs there
~~~
Expected results:
The line
~~~
ldap_result: Can't contact LDAP server (-1)
~~~
is not present and the utility successfully continues with plain LDAP protocol
as expected.
Additional info:
I'm attaching a full debug log (-d -1) to this bug.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8846
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|WONTFIX |INVALID
Status|RESOLVED |VERIFIED
--- Comment #10 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
Works as per RFC defined behavior
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8846
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Keywords|needs_review |
Resolution|--- |WONTFIX
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=5738
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords|needs_review |
Target Milestone|2.5.3 |2.6.0
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=5738
Ondřej Kuzník <ondra(a)mistotebe.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://bugs.openldap.org/s
| |how_bug.cgi?id=8064
--
You are receiving this mail because:
You are on the CC list for the issue.