389-ds-base

#49095 case sensitivity in ACI
Closed: wontfix Opened by dcrocker.

Closed: wontfix
Reopen Issue

We have used directory 389 for many years having migrated forward from the iPlanet/Sun version. Back when we were on Sun we discovered that any attribute listed in an ACI where we wanted to use a wildcard had to have the attribute name in all lower case. For instance, if we wanted to reference myAttribute when we had (myAttributeName1, myAttributeName2, etc) then in the ACI it had to be all lower case, as in myattribute. This holds true up through at least 1.2.11.15 which is our current production.

We are now testing 1.3.5.13, hoping to move our production forward into that. We’d been having trouble with some of our processes and have discovered that in the ACIs now the wildcard problem has switched its case sensitivity. In the newer server we have to change all our wildcard attributes to myAttribute*. I haven’t checked through all our schema values to see if there will be some spec’d with all lowercase (that is not our naming policy but we need to check). I also note that if the attribute is spelled out completely then it doesn’t matter about the case at all.

Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=1417344

Metadata Update from @nhosoi:
- Issue set to the milestone: 1.3.6.0

Metadata Update from @mreynolds:
- Issue assigned to mreynolds

@dcrocker do have an example of an aci that is causing you issues? Is it when you use targetattr? Or? Thanks!

Metadata Update from @mreynolds:
- Issue close_status updated to: None

 
(targetattr = "CN") (version 3.0;acl "Test attr insensitivity";deny (all)(userdn = "ldap:///anyone");)

Testing the ACI above I can not modify an entry's "cn" value as expected. Can we please get a reproducible test case?
Edited by mreynolds

@dcrocker can you please provide the aci that will reproduce the issue with attribute case sensitivity?

Metadata Update from @mreynolds:
- Custom field reviewstatus adjusted to new

My apologies. I did not realize it had not accepted my submission because I need to sign the agreement.

Here is one sample. This is what we use now. In the new version I have had to change all entries with a trailing "" to used caps. So, "uabama" becomes "uaBama", "eduperson" becomes eduPerson*, etc.

(targetattr = " sn || cn || givenName || uid || telephoneNumber || uagoogle || uaEntryLastAuthorized || uabama|| eduperson || uaKboxRole || uasponsor || uaradius || uaentry " ) (version 3.0;acl "ACI case sensitivity RO";allow (read,compare,search)(groupdn = "ldap:///cn=Account Manager,ou=Groups,dc=ua,dc=edu");)

Thanks @dcrocker, one last request. Can I see one of your user entries that contains some of the attributes from that aci? You can scrub all the values - I just want to see how the attribute names appear in the entry.

Well, I see it just dropped all of the asterisks in the ACI and all but one in my comment. In my sample it should follow uabama, eduperson, uaradius, uaentry, and, uagoogle. It has most definitely changed from me having to use all lower case to have to use the initial caps on the same LDAP directory data.

Here is a section of a sample entry:
dn:uid=-----,ou=People,dc=ua,dc=edu

            uaaffiliation: -----------------
           uaRadiusIFName: ---------------
                      uid: ---
        uaRadiusGroupName: ----------
       uaRadiusTunnelType: --
 uaRadiusTunnelMediumType: ---

uaRadiusTunnelPrivateGroupID: ---
eduPersonAffiliation: -----
eduPersonScopedAffiliation: -----------
-------------
-------------
objectClass: ---------------------
sn: -------------
givenName: -------------
cn: ----------------
uaBamaManager: ----
uaGoogle: ----
uaGoogleActiveStudent: ----
eduPersonPrimaryAffiliation: ----
eduPersonPrincipalName: ------------

0001-Issue-49095-targetattr-wildcard-evaluation-is-incorr.patch

Sending patch out for review...

Metadata Update from @mreynolds:
- Custom field reviewstatus adjusted to review (was: new)

The code looks good but i'm not sure about this test. The test looks like it adds a read aci then checks we can not read something?

Wouldn't it be better to check that the 4 aci's listed all individually and correctly allow access?

The code looks good but i'm not sure about this test. The test looks like it adds a read aci then checks we can not read something?
Wouldn't it be better to check that the 4 aci's listed all individually and correctly allow access?

The aci's allow anonymous access except to telephonenumber. The search uses telephoneNumber in the filter (which engages the aci). The bug is that the aci was not matching the resource, and incorrectly allowing access. So I feel the test is correct.

AHhhhhh I see it now. That makes more sense. Ack

Metadata Update from @firstyear:
- Custom field reviewstatus adjusted to ack (was: review)

4fb30a0..fdf78dc master -> master

f057563..ee63e40 389-ds-base-1.3.5 -> 389-ds-base-1.3.5

Metadata Update from @mreynolds:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/2154

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: fixed)
Metadata
None
None
None
Normal
ack
Community
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.