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.
https://bugs.openldap.org/show_bug.cgi?id=10086
Issue ID: 10086
Summary: test059 does not set up valid cn=config replication
Product: OpenLDAP
Version: 2.6.4
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: test suite
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
For cn=config replication to be valid, the entryUUIDs must match throughout the
config database. However, this is not the case when test059 executes. The
entryUUID for 'dn: cn=config' differs between the two.
Example:
quanah@apito1:~/git/quanah/openldap-scratch/tests/testrun$ grep entryUUID:
cfcon.d/cn\=config.ldif
entryUUID: aea058c4-bf6e-103d-9e18-4582986e9372
quanah@apito1:~/git/quanah/openldap-scratch/tests/testrun$ grep entryUUID:
db.1.a/cn\=config\,cn\=consumer.ldif
entryUUID: ae9bd858-bf6e-103d-871e-5daccf782d22
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10282
Issue ID: 10282
Summary: MSVC builds are not supported
Product: OpenLDAP
Version: 2.5.18
Hardware: All
OS: Windows
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: cmb(a)php.net
Target Milestone: ---
I'm a maintainer of an OpenLDAP port[1] which is used to build liblber and
libldap for PHP on Windows. So far this uses hand-made configuration and
Visual Studio solutions, but that is not sustainable in the long run. Instead,
I'd rather like to use the autotools based build chain with MSYS2 (or Cygwin),
but still using the MSVC build tools (cl.exe, link.exe, etc.) and the MS
Windows SDK for best compatibility with other builds for PHP on Windows.
Apparently, this is not yet supported by OpenLDAP (2.5.18).
I've managed to add some patches[2] to get where I'd like this to go[3]. Some
of the patches are highly PHP (BC) specific, some are just quick hacks (because
I don't know better), but some appear to be appropriate for inclusion into the
OpenLDAP sources.
Are you generally interested in supporting MSVC tools and MS Windows SDKs? If
so, what would be the best way to contribute -- sending MRs to the repo[4]?
Should these tackle individual issues, or rather be complete (note that I'm
likely not able to provide a full-fledged solution due to my very limited
knowledge of autotools and Linux, and limited time).
[1] <https://github.com/winlibs/openldap>
[2] <https://github.com/winlibs/openldap/tree/cmb/2.5.18>
[3] <https://github.com/cmb69/winlib-builder/actions/runs/11713086509>
[4] <https://git.openldap.org/openldap/openldap>
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9786
Issue ID: 9786
Summary: liblber: missing export of ber_pvt_wsa_err2string
Product: OpenLDAP
Version: 2.6.1
Hardware: All
OS: Windows
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: tobias.junghans(a)veyon.io
Target Milestone: ---
When building (cross-compiling) OpenLDAP via GCC/mingw-w64, an undefined
reference to ber_pvt_wsa_err2string() is reported when libldap.dll is linked.
This can be fixed easily by adding ber_pvt_wsa_err2string() to
libraries/liblber/lber.map
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9816
Issue ID: 9816
Summary: slapcat cordeumps during mdb subtree dump with -s
Product: OpenLDAP
Version: 2.5.11
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: khoffmann(a)united-internet.de
Target Milestone: ---
Created attachment 887
--> https://bugs.openldap.org/attachment.cgi?id=887&action=edit
gdb backtrace of slapcat run
When trying to use slapcat in combination with -b and -s in order to create a
LDIF backup of a mdb subtree, slapd crashes with a coredump (please see the
attached snippet with gdb output from a reproduced test tree). The problem was
reporducible with different mdb databases / suffixes and only appears with
option -s.
The same dump with -H 'ldap:///ou=users,o=company,c=de??sub?' instead of -s
ou=users,o=company,c=de works perfectly fine, as long as the "attrs part" is
empty in the ldap-uri. Also using slapcat with -b only (for a full database
dump) works fine as well.
I'm aware of the fact that -s option is marked as DEPRECATED - I'm not sure if
you are going to fix this bug or if you rather take the change to remove the
option completely from future major versions.
Please let me also know if it's expected behaviour that the -H option doesn't
work whenever the attribute part isn't empty and if I should contribute to a
documentation update for this edge case.
Best regards,
Kris
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9972
Issue ID: 9972
Summary: SSS needs READ instead of SEARCH access
Product: OpenLDAP
Version: 2.6.3
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: dpa-openldap(a)aegee.org
Target Milestone: ---
I have configured an OpenLDAP 2.6 server with
dn: olcDatabase=mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: mdb
olcAccess: to dn="cn=bodies,dc=aegee,dc=org"
by * search # no problem if this is READ
olcAccess: to dn.sub="dc=aegee,dc=org"
by * read
…
dn: olcOverlay=sssvlv,olcDatabase={1}mdb,cn=config
objectClass:olcOverlayConfig
The content of the tree is available anymously by calling
ldapsearch -ZZxH ldap://ldap.aegee.org -b "dc=aegee,dc=org" -s sub .
When I modify the call to use SSS:
ldapsearch -ZxH ldap://ldap.aegee.org -b "dc=aegee,dc=org" -s sub -E
sss=ou:2.5.13.15
it also returns results, but ends with
```
# search result
search: 93
result: 50 Insufficient access
# numResponses: 3
# numEntries: 2
```
When I modify above:
olcAccess: to dn="cn=bodies,dc=aegee,dc=org"
by * read
then the access is sufficient.
There is no entry called "dn:cn=bodies,dc=aegee,dc=org", or rather the entry
shall not be returned on searches and `ldapsearch -ZxH ldap://ldap.aegee.org -b
"dc=aegee,dc=org" -s sub` does not return it.
These work without a problem:
ldapsearch -ZxH ldap://ldap.aegee.org -b "cn=bodies,dc=aegee,dc=org" -s one -E
sss=ou:2.5.13.15
ldapsearch -ZxH ldap://ldap.aegee.org -b "cn=bodies,dc=aegee,dc=org" -s sub
ldapsearch -ZxH ldap://ldap.aegee.org -b "cn=bodies,dc=aegee,dc=org" -s one
This produces Insufficient access:
ldapsearch -ZxH ldap://ldap.aegee.org -b "cn=bodies,dc=aegee,dc=org" -s sub -E
sss=ou:2.5.13.15
That said client-side-sorting does work without a problem, but server-side
sorting requires not only SEARCH, but also READ privileges on
dn="cn=bodies,dc=aegee,dc=org".
I find this is a bug: SSS requires read-acesss to data, which is not supposed
to be returned to the client (dn:cn=bodies,dc=aegee,dc=org). For the
additional server-side sorting no additional privileges shall be required,
compared to returning the results without server-side-sorting.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9748
Issue ID: 9748
Summary: Deleted values of pwdFailureTime seem to reappear
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
Created attachment 854
--> https://bugs.openldap.org/attachment.cgi?id=854&action=edit
accesslog for uid=dm01-R2H2-956,ou=People,dc=example,dc=com
Somehow, ppolicy seems to be able to reference values of pwdFailureTime that
had been deleted before the actual bind even started. In the attached
accesslog, trace, deletion of everything (including "20211115154510.478330Z")
is recorded from reqSession: 3, then a bind comes in and the same value is
explicitly removed again.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9902
Issue ID: 9902
Summary: Make max index DBs for back-mdb configurable
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
From ITS#9895:
Currently there is a hardcoded limit of 128 index DBs in back-mdb. Some sites
want more than this (although there's no evidence they actually use more than
128 attributes in all of their applications' search filters).
For 2.5/2.6 we can simply double the constant. For 2.7 consider making it
configurable.
Note that increasing the number increases the size of an LMDB transaction
structure, and also increases the time needed to initialize it whenever
creating a transaction, so it's a bad idea to just set this to an arbitrarily
large number.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10332
Issue ID: 10332
Summary: Add support for SSLKEYLOGFILE environment variable to
export keys for Wireshark decryption
Product: OpenLDAP
Version: 2.6.9
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: michael.osipov(a)siemens.com
Target Milestone: ---
Please add support to do the following:
SSLKEYLOGFILE=keylog.txt ldapsearch -H ldaps://...
Other libraries and tools support it to decrypt the TLS traffic with Wireshark
for analysis purposes.
Curl has a simple, but complete implementation:
https://github.com/curl/curl/blob/e008f71f435a39875d86885a96b2eb8968a60fd4/…
Maybe it can be reused if license allows that?!
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9225
Bug ID: 9225
Summary: back-mdb: Add support for PREPARE/2-phase commit
Product: OpenLDAP
Version: 2.4.50
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Add support for PREPARE/2-phase commit in back-mdb
--
You are receiving this mail because:
You are on the CC list for the bug.