[Issue 9385] New: Opening an env with MDB_NOSUBDIR with no existing file returns error
by openldap-its@openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9385
Issue ID: 9385
Summary: Opening an env with MDB_NOSUBDIR with no existing file
returns error
Product: LMDB
Version: unspecified
Hardware: All
OS: Mac OS
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: kriszyp(a)gmail.com
Target Milestone: ---
Created attachment 776
--> https://bugs.openldap.org/attachment.cgi?id=776&action=edit
A fix to tolerate stat call on non-existing file
Calling mdb_env_open with a file path to a file that doesn't exist yet, with
MDB_NOSUBDIR on a non-Windows OS will return an error indicating that the file
doesn't exist. This is supposed to create a new file, and works properly on the
mdb.master branch, and still functions properly on Windows. The error is due to
the stat() call in mdb_env_open prior to the file existing.
I attached a patch that tolerates the absence of the file before checking if
the file is on a block device. I am not sure if this is the appropriate fix, or
if would be better to move this check later in mdb_env_open after the file is
created, or alternately, determining the parent directory and calling stat on
that.
--
You are receiving this mail because:
You are on the CC list for the issue.
1 year, 4 months
[Issue 9403] New: add option to completely disable syslog logging
by openldap-its@openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9403
Issue ID: 9403
Summary: add option to completely disable syslog logging
Product: OpenLDAP
Version: 2.4.45
Hardware: All
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: cvuillemez(a)yahoo.fr
Target Milestone: ---
For auditing purpose, I need to enable "stats" loglevel.
So on heavy load, slapd send lots of events to local syslog socket /dev/log,
when compiled with LDAP_SYSLOG (on Debian / Ubuntu).
It worked fine on old systems with a simple syslog service.
But when upgrading on system with journald+syslog, CPU "overhead" becomes
totally crazy.
It would be great to have an option at run time to completely disable syslog
logging, or/and use a cutom socket, e.g. /run/systemd/journal/syslog to bypass
journald service.
--
You are receiving this mail because:
You are on the CC list for the issue.
1 year, 4 months
[Bug 9256] New: The ACLs required for SASL binding are not fully documented
by openldap-its@openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9256
Bug ID: 9256
Summary: The ACLs required for SASL binding are not fully
documented
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: documentation
Assignee: bugs(a)openldap.org
Reporter: kop(a)karlpinc.com
Target Milestone: ---
Created attachment 727
--> https://bugs.openldap.org/attachment.cgi?id=727&action=edit
Patch massaging the SASL binding requirement docs
While some ACL requirements for SASL binding are documented, some are not.
E.g, that olcAuthzRegexp requires =x on objectClass when direct DN mapping is
not documented. Other requirements can be reasoned out based on the existing
documentation, but this can be very difficult when unfamiliar with all the
moving parts and the places they are documented. E.g. knowing that
(objectClass=*) is the default filter, and that there's _always_ _some_ filter,
and connecting this with ACLs required to do search-based SASL mapping.
The attached patch brings all the SASL binding requirements together in one
place in the docs and makes everything explicit. The word "SASL" is included,
for those searching for that keyword.
I, Karl O. Pinc, hereby place the following modifications to OpenLDAP Software
(and only these modifications) into the public domain. Hence, these
modifications may be freely used and/or redistributed for any purpose with or
without attribution and/or other notice.
--
You are receiving this mail because:
You are on the CC list for the bug.
1 year, 7 months
[Bug 9189] New: Add GSSAPI channel-bindings support
by openldap-its@openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9189
Bug ID: 9189
Summary: Add GSSAPI channel-bindings support
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: iboukris(a)gmail.com
Target Milestone: ---
Recently MS has announce they plan to enforce channel-bindings for LDAP over
TLS (ADV190023).
To support it on client side, we need to pass "tls-endpoint" bindings (RFC
5929) to the SASL plugin, and make use of that in GSSAPI.
See also:
https://github.com/cyrusimap/cyrus-sasl/pull/601
--
You are receiving this mail because:
You are on the CC list for the bug.
1 year, 7 months
[Issue 9350] New: Expand test suite for null base
by openldap-its@openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9350
Issue ID: 9350
Summary: Expand test suite for null base
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Currently we have no tests that use the empty suffix (null base).
This is an entirely valid configuration setup, and there are unique challenges
and bugs that crop up with this usage.
We need to ensure we're covering this use case, particularly with syncrepl and
delta-syncrepl configurations.
--
You are receiving this mail because:
You are on the CC list for the issue.
1 year, 8 months
[Issue 9282] New: Syncrepl re-creates deleted entry
by openldap-its@openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9282
Issue ID: 9282
Summary: Syncrepl re-creates deleted entry
Product: OpenLDAP
Version: 2.4.50
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Scenario:
2 node Multi-provider replication
Add database to provider A
ensure database replicates to provider B
Stop provider A
delete entry on provider B
Start provider A
Wait for provider B to reconnect to provider A
Deleted entry re-appears
--
You are receiving this mail because:
You are on the CC list for the issue.
1 year, 9 months
[Issue 9356] New: Add list of peerSIDs to consumer cookie to reduce cross traffic
by openldap-its@openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9356
Issue ID: 9356
Summary: Add list of peerSIDs to consumer cookie to reduce
cross traffic
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
If we add a list of peersids to the cookie, each consumer can tell the
providers who else the consumers talk to and then the provider can omit sending
updates to that consumer, originating from those peers
There's some special handling needed if a connection dies
If a consumer loses one of its peer connections, and after N retries is still
not connected, it should send a new cookie to its remaining peers saying
"here's my new peer list" with the missing one removed. Likewise, if a retry
eventually connects again, it can send a new cookie again
Make that peer list reset configurable in the syncrepl config stanza. This can
help account for end admin knowledge that some links may be more or less stable
than other ones.
The idea here is that if one of your other peers can still see the missing
peer, they can start routing updates to you again
It should abandon all existing persist sessions and send a new sync search with
the new cookie to all remaining peers
For consumer side, also means adding the sid for a given provider into the
syncrepl stanza to save on having to try and discover the peer sid.
--
You are receiving this mail because:
You are on the CC list for the issue.
1 year, 10 months
[Issue 9393] New: Provider a LDAP filter validation function
by openldap-its@openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9393
Issue ID: 9393
Summary: Provider a LDAP filter validation function
Product: OpenLDAP
Version: 2.4.56
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: best(a)univention.de
Target Milestone: ---
In many situations I need to validate if a user submitted LDAP filter has valid
syntax.
It seems there is no official function to check this.
Could you provide one?
libraries/libldap/filter.c: ldap_pvt_put_filter() can be used as a basis.
--
My current workaround is using a unconnected ldap connection and do a search
with that filter. This yields a FILTER_ERROR (invalid filter) or a SERVER_DOWN
error (invalid filter).
See also:
https://github.com/python-ldap/python-ldap/pull/272
--
You are receiving this mail because:
You are on the CC list for the issue.
1 year, 11 months
[Issue 9428] New: DoS due to infinite packet processing in slapd
by openldap-its@openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9428
Issue ID: 9428
Summary: DoS due to infinite packet processing in slapd
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: phasip(a)gmail.com
Target Milestone: ---
Processing of a packet results in the command handling thread becomming stuck
in an infinite loop.
After sending 32 of theese slapd doesn't respond to any new queries and
consumes 100% cpu
Packet
00000000: 3036 0200 7730 300b 312e 332e 362e 312e 06..w00.1.3.6.1.
00000010: 312e 3881 1030 0130 0030 3030 3030 3030 1.8..0.0.0000000
00000020: 3030 3030 3030 0030 3030 3030 3030 3030 000000.000000000
00000030: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000
00000040: 30 0
GDB backtrace
(gdb) thread 3
[Switching to thread 3 (Thread 0x7fff8aad2700 (LWP 12))]
#0 0x00007ffff7eb489b in sched_yield ()
at ../sysdeps/unix/syscall-template.S:78
78 ../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb) bt
#0 0x00007ffff7eb489b in sched_yield ()
at ../sysdeps/unix/syscall-template.S:78
#1 0x0000555555671671 in ldap_pvt_thread_yield () at thr_posix.c:249
#2 0x00005555555d9255 in cancel_extop (op=0x7fff7c001160, rs=<optimized
out>)
at cancel.c:143
#3 0x00005555555b449a in fe_extended (op=0x7fff7c001160,
rs=0x7fff8aad1a80)
at extended.c:225
#4 0x00005555555b41c2 in do_extended (op=0x7fff7c001160,
rs=0x7fff8aad1a80)
at extended.c:175
#5 0x0000555555583d09 in connection_operation
(ctx=ctx@entry=0x7fff8aad1ba0,
arg_v=0x7fff7c001160) at connection.c:1163
#6 0x0000555555584370 in connection_read_thread (ctx=0x7fff8aad1ba0,
argv=0xc)
at connection.c:1314
#7 0x0000555555671080 in ldap_int_thread_pool_wrapper
(xpool=0x555555799240)
at tpool.c:1051
#8 0x00007ffff7faa609 in start_thread (arg=<optimized out>)
at pthread_create.c:477
#9 0x00007ffff7ed1293 in clone ()
at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Testing:
docker run --privileged -it --net=host --entrypoint gdb phasip/openldap
/openldap/servers/slapd/slapd -ex 'set args -h ldap://:1389/ -d 256' -ex 'run'
for i in {1..32}; do echo -en
'\x30\x36\x02\x00\x77\x30\x30\x0b\x31\x2e\x33\x2e\x36\x2e\x31\x2e\x31\x2e\x38\x81\x10\x30\x01\x30\x00\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x00\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30'
| timeout 1 nc localhost 1389 & done
--
You are receiving this mail because:
You are on the CC list for the issue.
2 years
[Issue 9443] New: Admin guide: Need section on lloadd and load balancer as slapd module
by openldap-its@openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9443
Issue ID: 9443
Summary: Admin guide: Need section on lloadd and load balancer
as slapd module
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: blocker
Priority: ---
Component: documentation
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
The admin guide currently has no documentation on the new lloadd daemon or the
ability to set up the load balancer as a module inside of slapd. This is a
release requirement.
--
You are receiving this mail because:
You are on the CC list for the issue.
2 years, 1 month