search

389ds / 389-ds-base

The enterprise-class Open Source LDAP server for Linux
https://www.port389.org/
Other
210 stars 90 forks source link

Filter (attr=*) does not match objects if ACL allows access to sub-type only #1456

Closed 389-ds-bot closed 1 year ago

389-ds-bot commented 4 years ago

Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/48125

Version: 389-ds-base-1.3.3.8-1.fc21.x86_64

When discussing [ticket 157]]([https://fedorahosted.org/bind-dyndb-ldap/ticket/157|bind-dyndb-ldap) we found out that filter with presence condition interacts weirdly with ACIs which allow access only to sub-types.

Test object

$ ldapsearch -Y GSSAPI -s base -b 'idnsname=txt,idnsname=ipa.example.,cn=dns,dc=ipa,dc=example'
SASL username: admin@IPA.EXAMPLE

# txt, ipa.example., dns, ipa.example
dn: idnsname=txt,idnsname=ipa.example.,cn=dns,dc=ipa,dc=example
objectClass: top
objectClass: idnsrecord
tXTRecord: nothing
tXTRecord: something
idnsName: txt
tXTRecord;test: Guess what is new here!

ACL

(targetattr = "objectclass || txtRecord;test")
(target = "ldap:///idnsname=*,cn=dns,dc=ipa,dc=example")
(version 3.0;acl "permission:luser: Read DNS Entries";
allow (compare,read,search)
userdn = "ldap:///uid=luser,cn=users,cn=accounts,dc=ipa,dc=example";)

Search tests

ACL correctly allows access only to the sub-type in question:

$ ldapsearch -Y GSSAPI -s base -b idnsname=txt,idnsname=ipa.example.,cn=dns,dc=ipa,dc=example'
SASL username: luser@IPA.EXAMPLE

# txt, ipa.example., dns, ipa.example
dn: idnsname=txt,idnsname=ipa.example.,cn=dns,dc=ipa,dc=example
objectClass: top
objectClass: idnsrecord
tXTRecord;test: Guess what is new here!

Filter (tXTRecord;test=*) works as expected and returns only objects which have an attribute with subtype ;test.

Interestingly, search filter (tXTRecord=*) does not return the same object if the ACI allows access to the subtype ;test with existing value but not to the 'vanilla' attribute without subtype.

I would expect that search filter (tXTRecord=*) will return the object if at least one attribute value is accessible to the client. Of course, I could be wrong :-)

389-ds-bot commented 4 years ago

Comment from nkinder (@nkinder) at 2015-03-11 19:35:03

Replying to [ticket:48125 pspacek]:

Interestingly, search filter (tXTRecord=*) does not return the same object if the ACI allows access to the subtype ;test with existing value but not to the 'vanilla' attribute without subtype.

I would expect that search filter (tXTRecord=*) will return the object if at least one attribute value is accessible to the client. Of course, I could be wrong :-)

Subtypes work the other way. An attribute with a specified subtype (like 'tXTRecord;test') is considered to be more specific than just the basetype ('tXTRecord'). If you are granted access to the basetype, I would expect you to have access to the basetype and any subtype. If you are granted access to a specific subtype, you should not have access to the basetype or any other subtypes.

389-ds-bot commented 4 years ago

Comment from pspacek at 2015-03-12 17:23:26

I'm confused.

a) If I grant access to the whole object: Filter (attr=*) returns objects which has only attr present along with objects which has only attr;subtype present.

$ ldapsearch -Y GSSAPI -s base -b 'idnsname=txt-subtype-only,idnsname=ipa.example.,cn=dns,dc=ipa,dc=example' '(tXTRecord=*)' txtRecord
SASL username: admin@IPA.EXAMPLE

# txt-subtype-only, ipa.example., dns, ipa.example
dn: idnsname=txt-subtype-only,idnsname=ipa.example.,cn=dns,dc=ipa,dc=example
tXTRecord;test: the only value is in sub-type

This is what I expect.

b) If I grant access to the one particular sub-type of attr the very same search behaves differently. Filter (attr=*) returns nothing even if attr;subtype attribute is present and accessible. 

$ ldapsearch -Y GSSAPI -s base -b 'idnsname=txt-subtype-only,idnsname=ipa.example.,cn=dns,dc=ipa,dc=example' '(tXTRecord=*)' txtRecord
SASL username: luser@IPA.EXAMPLE

# search result
search: 4
result: 0 Success

This seems to be inconsistent with behavior for case a). IMHO either ACI processing or filter engine is behaving inconsistently.

389-ds-bot commented 4 years ago

Comment from nhosoi (@nhosoi) at 2016-05-13 00:20:12

Per triage, push the target milestone to 1.3.6.

389-ds-bot commented 4 years ago

Comment from pspacek at 2017-02-11 22:57:25

Metadata Update from @pspacek:

389-ds-bot commented 4 years ago

Comment from mreynolds (@mreynolds389) at 2017-05-08 22:28:33

Metadata Update from @mreynolds389:

389-ds-bot commented 4 years ago

Comment from mreynolds (@mreynolds389) at 2020-05-27 21:31:46

Metadata Update from @mreynolds389:

389-ds-bot commented 4 years ago

Comment from mreynolds (@mreynolds389) at 2020-05-27 21:32:09

Metadata Update from @mreynolds389:

vashirov commented 1 year ago

Per triage meeting, closing as WORKSFORME.