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.
$ 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!
(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";)
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.
(tXTRecord;test=*)
;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.
(tXTRecord=*)
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 :-)
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.
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
(attr=*)
attr
attr;subtype
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: 4 result: 0 Success }}}
This seems to be inconsistent with behavior for case a). IMHO either ACI processing or filter engine is behaving inconsistently.
Per triage, push the target milestone to 1.3.6.
Metadata Update from @pspacek: - Issue set to the milestone: 1.3.6.0
Metadata Update from @mreynolds: - Custom field component reset (from Security - Access Control (ACL)) - Issue close_status updated to: None - Issue set to the milestone: 1.4 backlog (was: 1.3.6.0)
Metadata Update from @mreynolds: - Custom field reviewstatus adjusted to None - Issue set to the milestone: 1.4.5 (was: 1.4 backlog)
Metadata Update from @mreynolds: - Issue tagged with: Access Control
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/1456
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.