https://bugs.openldap.org/show_bug.cgi?id=9216
Bug ID: 9216
Summary: Port autoca to gnutls
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: ryan(a)openldap.org
Target Milestone: ---
For 2.5, support building and running the autoca overlay with GnuTLS.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9204
Bug ID: 9204
Summary: slapo-constraint allows anyone to apply Relax control
Product: OpenLDAP
Version: 2.4.49
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: ryan(a)openldap.org
Target Milestone: ---
slapo-constraint doesn't limit who can use the Relax control, beyond the global
limits applied by slapd. In practice, for many modifications this means any
configured constraints are advisory only.
In my opinion this should be considered a bug, in design if not implementation.
I expect many admins would not read the man page closely enough to realize the
behaviour does technically adhere to the letter of what's written there.
Either slapd should require manage privileges for the Relax control globally,
or slapo-constraint should perform a check for manage privilege itself, like
slapo-unique does.
Quoting ando in https://bugs.openldap.org/show_bug.cgi?id=5705#c4:
> Well, a user with "manage" privileges on related data could bypass
> constraints enforced by slapo-constraint(5) by using the "relax"
> control. The rationale is that a user with manage privileges could be
> able to repair an entry that needs to violate a constraint for good
> reasons. Note that the user:
>
> - must have enough privileges to do it (manage)
>
> - must inform the DSA that intends to violate the constraint (by using
> the control)
but such privileges are currently not being required.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9278
Issue ID: 9278
Summary: liblmdb: robust mutexes should not be unmapped
Product: LMDB
Version: unspecified
Hardware: All
OS: FreeBSD
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: delphij(a)freebsd.org
Target Milestone: ---
Created attachment 736
--> https://bugs.openldap.org/attachment.cgi?id=736&action=edit
A possible workaround
We recently noticed that lmdb would have the memory region containing the
robust mutex unmapped on mdb_env_close0():
munmap((void *)env->me_txns,
(env->me_maxreaders-1)*sizeof(MDB_reader)+sizeof(MDB_txninfo));
Note that if this is the last unmap for a robust mutex, the FreeBSD
implementation would garbage-collect the mutex, making it no longer visible to
other processes. As the result, a second instance of the attached test.c (from
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244493 with minor changes)
would trigger the assertion at mdb_txn_begin() because the acquisition of the
mutex would return 22 (EINVAL), because the mutex appeared to be a robust
mutex, but was invalid.
The attached lmdb.diff is a possible workaround for this (it would skip
unmapping when setting up the robust mutex for the first time).
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9714
Issue ID: 9714
Summary: Use xorshift in libldap/dnssrv.c
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
As discussed in https://git.openldap.org/openldap/openldap/-/merge_requests/417
we may want to shift to using xorshift in libldap/dnssrv.c in a future release.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9735
Issue ID: 9735
Summary: [PATCH] try hard to find free space if database cannot
grow
Product: LMDB
Version: 0.9.24
Hardware: All
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: libor.peltan(a)nic.cz
Target Milestone: ---
Created attachment 851
--> https://bugs.openldap.org/attachment.cgi?id=851&action=edit
Patch fixing the issue "try hard to find free space if database cannot grow"
Note:
- the issue is the same in version 0.9.70 (git)
Situation:
- the database had already grown to its limit (mapsize) in the past
- overflow pages are used heavily as stored values are usually several pages
long
- free space got fragmented
Problem:
- attempt to insert new value results in MDB_MAP_FULL despite there is free
space available
Cause: there is a heursitic in mdb_page_alloc() that gives up searching for
free space chunk if this would take too much time. This is useful when the
database can still grow, as it balances performance with space usage. However,
if the database can no longer grow, it prevents inserting new values.
Solution: detect early on in mdb_page_alloc() if the database can grow, and if
not, let it try hard to search for free space.
Patch: attached
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9471
Issue ID: 9471
Summary: Add RBAC overlay to core
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Symas will contribute its RBAC overlay to core
The slapo-rbac overlay is an implementation of the ANSI INCITS 359 Role-Based
Access Control (RBAC) Core.
When instantiated, it intercepts, decodes and enforces specific RBAC policies
per the Apache Fortress RBAC data formats.
The overlay provides a set of extended operations.
They include session create/delete, checkAccess, addActiveRole, dropActiveRole
and sessionRoles.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9472
Issue ID: 9472
Summary: Add datamorph overlay to core
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Symas will contribute its datamorph overlay to core
The datamorph overlay to slapd allows attributes with a few predefined values
to be saved more space-efficiently as well as signed or unsigned integer
attributes.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9473
Issue ID: 9473
Summary: Add variant overlay to core
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Symas will contribute its variant overlay to OpenLDAP core
The variant overlay to slapd allows attributes/values to be shared between
several entries. In some ways this is similar to slapo-collect with the
exception that the source and target attributes can be different.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9813
Issue ID: 9813
Summary: Incompatibility between remoteauth and ppolicy
overlays
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: thierry.pubellier(a)paris.fr
Target Milestone: ---
Hi,
We are planning to use OpenLDAP as a proxy for some users in our Active
Directory servers, using remoteauth overlay.
We want this OpenLDAP instance to also implement an account lockout policy,
preventing the lockout on our internal Active Directory servers.
But there seems to be an incompatibility between remoteauth and ppolicy
overlays : remoteauth won't remote authenticate a user if local userPassword
attribute exists, while ppolicy overlay needs this attribute.
Could there be a configuration parameter in ppolicy to allow lockout
checks/modifications (which seemed to be the default behavior of OpenLDAP
before ITS#7089) ?
I can provide a patch if allowed.
Thanks by advance,
Best regards,
Thierry
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9827
Issue ID: 9827
Summary: Feature request for module argon2.so to support
Argon2i, Argon2d, Argon2id
Product: OpenLDAP
Version: 2.6.1
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: juergen.sprenger(a)swisscom.com
Target Milestone: ---
Hi,
This is a feature request.
I would like to be able to chooses between Argon2i, Argon2d and Argon2id in
slappasswd like in argon2 command:
# argon2
Usage: argon2 [-h] salt [-i|-d|-id] [-t iterations] [-m log2(memory in KiB) |
-k memory in KiB] [-p parallelism] [-l hash length] [-e|-r] [-v (10|13)]
Password is read from stdin
Parameters:
salt The salt to use, at least 8 characters
-i Use Argon2i (this is the default)
-d Use Argon2d instead of Argon2i
-id Use Argon2id instead of Argon2i
-t N Sets the number of iterations to N (default = 3)
-m N Sets the memory usage of 2^N KiB (default 12)
-k N Sets the memory usage of N KiB (default 4096)
-p N Sets parallelism to N threads (default 1)
-l N Sets hash output length to N bytes (default 32)
-e Output only encoded hash
-r Output only the raw bytes of the hash
-v (10|13) Argon2 version (defaults to the most recent version,
currently 13)
-h Print argon2 usage
Example:
/usr/local/etc/openldap # /usr/sbin/slappasswd -h "{ARGON2}" -o
module-load="argon2.so i" -s secret
/usr/local/etc/openldap # /usr/sbin/slappasswd -h "{ARGON2}" -o
module-load="argon2.so d" -s secret
/usr/local/etc/openldap # /usr/sbin/slappasswd -h "{ARGON2}" -o
module-load="argon2.so id" -s secret
Best regards
Juergen Sprenger
--
You are receiving this mail because:
You are on the CC list for the issue.