Issue 8182 - setspec matching fails unexpectedly
Summary: setspec matching fails unexpectedly
Status: VERIFIED SUSPENDED
Alias: None
Product: OpenLDAP
Classification: Unclassified
Component: slapd (show other issues)
Version: 2.4.40
Hardware: All All
: --- development
Target Milestone: ---
Assignee: OpenLDAP project
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-07-01 19:06 UTC by daniel.kauffman@rocksolidsolutions.org
Modified: 2023-11-02 16:43 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description daniel.kauffman@rocksolidsolutions.org 2015-07-01 19:06:44 UTC
Full_Name: Daniel Kauffman
Version: 2.4.40
OS: Debian 8.1
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (76.178.89.137)


Issue:

Using access control set=<setspec> to compare an attribute value against a
string converts the attribute value to lower case but does not convert the
string to lower case, so matching sometimes fails unexpectedly.

Expected behavior:

When an attribute value is compared against a string, matching should use the
attribute equality matching rule to determine whether or not to do a
case-sensitive match. An exact match would not convert either the attribute
value or the string, and a case-insensitive matching rule would convert both the
attribute value and the string for comparison.

Steps to reproduce:

Create a user objectclass with a roleName attribute and set the attribute value
to "canBrowse". Note the mixed case.

Create an access control statement with mixed case:

olcAccess: to * by set="user/roleName & [canBrowse]" read

Because the roleName attribute value is converted to lower-case before
comparison, the above will always fail, regardless of the case of the roleName
attribute value.

However, this works, regardless of the case of the roleName attribute value:

olcAccess: to * by set="user/roleName & [canbrowse]" read
Comment 1 Quanah Gibson-Mount 2017-04-03 16:48:04 UTC
moved from Incoming to Software Bugs
Comment 2 Ondřej Kuzník 2020-06-03 14:50:21 UTC
Dealing with this would need access to the attribute type in the other set we're joining with so the literal 'canBrowse' could be normalised accordingly.

But the way set ACLs are parsed at the moment, there is no way to keep and propagate this information. We might have to turn to a parser generator to get an AST and annotate accordingly if this is needed. That would in turn make us require YACC or whatever we chose.
Comment 3 Quanah Gibson-Mount 2023-11-02 16:43:38 UTC
patches welcome, has usable workaound