https://bugs.openldap.org/show_bug.cgi?id=9592
Issue ID: 9592
Summary: recursion operator (*) for acl “sets” does not work as
documented
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: grapvar(a)gmail.com
Target Milestone: ---
I have traced how the slapd computes recursion operator (*) in acl's “sets” and
found out that it does not work as documented. IIUC, the reference
documentation is:
“Sets in Access Controls”
(http://www.openldap.org/faq/index.cgi?file=1133)
To make things simpler, I report the finding using the example provided by the
documentation. Here it is:
entry "cn=Group" has attr "member" with values { "cn=User", "cn=Other" }
entry "cn=Group2" has attr "member" with values { "cn=Group", "cn=Person" }
The documentation claims that the expression
“[cn=Group2]/member*” resolves to { "cn=User", "cn=Other", "cn=Person" }
In fact, it resolves to { "cn=Group", "cn=User", "cn=Other", "cn=Person" }.
To generalize: all intermediate dn's persist in a set, that's how set_chase(
closure = 1 ) works, and this doesn't look like that's how it's supposed to
work.
Be advised, please, that this issue has been reported by occasional visitor,
from a developer point of view, not a user point of view, so I won't define,
provide or construct any “valid use case”.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9595
Issue ID: 9595
Summary: indeterminate result of matching AVA in filter
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: grapvar(a)gmail.com
Target Milestone: ---
I have traced how test_ava_filter() matches an entry against an AVA and found
out that result of matching may be indeterminate.
For concreteness, let us suppose an entry E is being matched against equality
ava (A1=U). E has a few values for A1, in this particular order:
Attr Value (A1=U) match
---- ----- ------------
A1 V False
A1 U True
A1 @$%#^ #LDAP_INVALID_SYNTAX
overall matching result: TRUE.
But what if A1 values follow in other order?
Attr Value (A1=U) match
---- ----- ------------
A1 V False
A1 @$%#^ #LDAP_INVALID_SYNTAX
A1 U True
overall matching result: #LDAP_INVALID_SYNTAX.
But... wait, E has one more attribute A2, which subclasses A1. And their values
happen to be in this order:
Attr Value (A1=U) match
---- ----- ------------
A1 V False
A1 @$%#^ #LDAP_INVALID_SYNTAX
A1 U True
A2 U True
A2 *%#$! #LDAP_INVALID_SYNTAX
overall matching result: TRUE again.
It seems rather unnatural and confusing that the given set of attributes and
their values has indeterminate result of matching.
Be advised, please, that this issue has been reported by occasional visitor,
from a developer point of view, not a user point of view, so I won't define,
provide or construct any “valid use case”.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9594
Issue ID: 9594
Summary: The characters not allowed in SASL ids used with
olcAuthzRegexp are undocumented
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: documentation
Assignee: bugs(a)openldap.org
Reporter: kop(a)karlpinc.com
Target Milestone: ---
Some characters cannot be used in SASL ids processed by the SASL mechanism that
olcAuthzRegexp configures. It is undocumented which characters are allowed and
which are not.
See also ITS bug number 9495.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9495
Issue ID: 9495
Summary: authz-regexp using dn: instead of a URI mangles
characters with HTML excapes
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: kop(a)karlpinc.com
Target Milestone: ---
Trying to use an authz-regexp that maps directly to dn-s by using "dn:..."
instead of a URI results in the authz id having some characters "html escaped".
As a result the authorized entity cannot be found.
E.g. a "-U cn=Barbara Jensen,ou=Information Technology Division"
with
olcAuthzRegexp: "^uid=([^,]+),.*" "dn:$1,ou=people,dc=example,dc=com"
fails. Debug logs show that the equal and the comma character return from
ldap_bv2dn() in escaped forms, that are then substituted into the target dn and
result in a dn that does not exist in the DIT.
6046d7cd SASL Canonicalize [conn=1113]: authcid="cn=Barbara
Jensen,ou=Informatio
n Technology Division"
6046d7cd slap_sasl_getdn: conn 1113 id=cn=Barbara Jensen,ou=Information
Technolo
gy Division [len=52]
=> ldap_dn2bv(16)
<= ldap_dn2bv(uid=cn\3DBarbara Jensen\2Cou\3DInformation Technology
Division,cn=PLAIN,cn=auth)=0
6046d7cd slap_sasl_getdn: u:id converted to uid=cn\3DBarbara
Jensen\2Cou\3DInformation Technology Division,cn=PLAIN,cn=auth
...
6046d7cd send_ldap_result: err=49 matched="" text="SASL(-13): user not found:
Password verification failed"
I suspect that when the "dn:..." form is used with authz-regexp the supplied
authzid should _not_ have it's characters canonicalized because they will not
be substituted into a URI. If so, this would be a bug. If not, there should
be documentation on the restrictions on what characters can be used in authzid
when the "dn:..." form is used.
Tested against HEAD of master, although the version in the bug report is 2.5.
See also Bug# 6912.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8788
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|IN_PROGRESS |RESOLVED
Resolution|--- |TEST
--- Comment #4 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
Commits:
• f6dcc600
by Quanah Gibson-Mount at 2021-06-24T17:48:21+00:00
ITS#8788 - Document that "undef" is not usable with back-mdb
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8874
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|IN_PROGRESS |RESOLVED
Resolution|--- |TEST
--- Comment #5 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
Commits:
• 59f8d06d
by Quanah Gibson-Mount at 2021-06-24T15:01:51+00:00
ITS#8874 - Don't try and link in libcom_err with libfetch on FreeBSD
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=7239
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|bugs(a)openldap.org |hyc(a)openldap.org
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=6916
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|bugs(a)openldap.org |hyc(a)openldap.org
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=6878
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |VERIFIED
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=6878
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |SUSPENDED
Status|UNCONFIRMED |RESOLVED
--- Comment #11 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
Likely resolved at this point.
--
You are receiving this mail because:
You are on the CC list for the issue.