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=9909
Issue ID: 9909
Summary: slap* tools leak cn=config entries on shutdown
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: ---
slap* tools set up their in-memory cn=config structures but cfb->cb_root is
never released on shutdown.
--
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=9881
Issue ID: 9881
Summary: Ability to track last authentication for database
objects
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
For simple binds, we have the ability to track the last success via the
lastbind functionality (pwdLastSuccess attribute). However this doesn't allow
one to see when an object that exists in a database last authenticated via
SASL.
It would be useful to add similar functionality for SASL binds.
This can be useful information that allows one to tell if an object is being
actively authenticated to (generally, users and system accounts, etc).
Obviously if something is directly mapped to an identity that doesn't exist in
the underlying DB, that cannot be tracked.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9829
Issue ID: 9829
Summary: set timeouts in remoteauth overlay
Product: OpenLDAP
Version: 2.5.11
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: david.coutadeur(a)gmail.com
Target Milestone: ---
Currently, it seems there is no way to configure timeouts in the remoteauth
overlay.
For example, if I define a remoteauth_mapping with a file containing a
list of hostnames, the first one is checked first.
After "remoteauth_retry_count" * "connect_timeout" seconds, (210s on my
system), remoteauth test the second server in the list.
In some circumstances, it could be nice to set the connect timeout lower
(or higher).
--
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=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=9739
Issue ID: 9739
Summary: Undefined reference to ber_sockbuf_io_udp in 2.6.0
Product: OpenLDAP
Version: 2.6.0
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: simon.pichugin(a)gmail.com
Target Milestone: ---
While I was trying to build OpenLDAP 2.6 on Fedora Rawhide I've got the error
message:
/usr/bin/ld: ./.libs/libldap.so: undefined reference to
`ber_sockbuf_io_udp'
I've checked commits from https://bugs.openldap.org/show_bug.cgi?id=9673 and
found that 'ber_sockbuf_io_udp' was not added to
https://git.openldap.org/openldap/openldap/-/blob/master/libraries/liblber/…
I've asked on the project's mailing list and got a reply:
"That symbol only exists if OpenLDAP is built with LDAP_CONNECTIONLESS
defined, which is not a supported feature. Feel free to file a bug report
at https://bugs.openldap.org/"
https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/…
Hence, creating the bug.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9782
Issue ID: 9782
Summary: regression test its8752 failure
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: ---
If a contextCSN update (new cookie) goes from server A through server B to
server C, server C will use that CSN to update entryCSN as well (which neither
A nor B did). This fails the initial replication check.
The issue has likely existed since deltasync was made possible, a version of
this is confirmed at least in 2.4.60 onwards to current master. In principle,
it is related to concerns raised in ITS#9580.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9652
Issue ID: 9652
Summary: Add "tee" capability to load balancer
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: lloadd
Assignee: bugs(a)openldap.org
Reporter: mhardin(a)symas.com
Target Milestone: ---
This is a request for an enhancement that would add a "tee" or "fan-out"
capability to load balancer, where received operations are sent to two or more
destinations simultaneously.
The primary goal or the enhancement is to make it possible to keep multiple
independent and likely dissimilar directory systems in lock-step with each
other over hours, days, or possibly even weeks.
The enhancement would not necessarily need to include a mechanism for
converging the target systems should they become out of sync.
This is not intended to be a replication solution, rather it is viewed more as
a "copy" solution intended to be used for specific short-term tasks that need
multiple directory systems to be exactly synchronized but where replication is
not desirable or even possible.
At least two uses come to mind:
1. Test harnesses, evaluating side-by-side operation of separate directory
systems over time
2. Directory system transition validation harnesses
3. (maybe) Part of a test harness to record or replay LDAP workloads
* Other uses?
--
You are receiving this mail because:
You are on the CC list for the issue.