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=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=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.
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=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=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.
https://bugs.openldap.org/show_bug.cgi?id=9768
Issue ID: 9768
Summary: slapo-translucent handling of deletion of multi-valued
configuration attributes removes wrong value from list
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
If olcTranslucentLocal/olcTranslucentRemote is passed multiple attribute names
in a single value that (or one further down the list) is later removed, the
overlay doesn't handle its removal correctly. We should encourage users to
provide a single attribute name per value, just like we do in EMIT for those
provided in slapd.conf.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9767
Issue ID: 9767
Summary: slapo-unique handling of deletion of multi-valued
configuration attributes removes wrong value from list
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
If olcUniqueIgnore/olcUniqueAttribute is passed multiple names in a single
value that is later removed, the overlay doesn't handle its removal correctly.
We should encourage users to provide a single attribute name per value, just
like we do in EMIT for those provided in slapd.conf.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9343
Issue ID: 9343
Summary: Expand ppolicy policy configuration to allow URL
filter
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: ---
Currently, ppolicy only supports a single global default policy, and past that
any policies must be manually added to a given user entry if they are supposed
to have something other than the default policy.
Also, some sites want no default policy, and only a specific subset to have a
policy applied to them.
For both of these cases, it would be helpful if it were possible to configure a
policy to apply to a set of users via a URL similar to the way we handle
creating groups of users in dynlist
--
You are receiving this mail because:
You are on the CC list for the issue.