#47679 aci allows to add an entry although targattrfilter does not match the added entry
Closed: wontfix Opened by tbordaz.

When adding this aci:

aci: (target = "ldap:///cn=*,dc=example,dc=com")(targattrfilters="add=member:(
 member=cn=bind_entry, dc=example,dc=com)")(targetfilter ="(objectClass=OCtick
 et47653)")(version 3.0; acl "SelfDN add"; allow (add) userdn = "ldap:///anyon
 e";)

We can expect that any bound user can not ADD an entry, if that entry does not contain the attribute:

member=cn=bind_entry, dc=example,dc=com

The attached test case, succeeds to create an entry.


I am not sure if the bahaviour is really incorrect. The doc reaarding the requested rights for specific ldap operations:
Adding an entry:
Grant add permission on the entry being added.
Grant write permission on the value of each attribute in the entry. This right is granted by default but could be restricted using the targattrfilters keyword.

I think the tagrattrfilters can restrict values of an attribute, but does not make it a required attribute. So if it is missing in the entry added, it will not be checked and for al otehr attributes the permission is implictely granted.

The aci should prevent the adding od an entry with a member: "something differerent" attribute

I agree with you doc describes 'targetattrfilters' for an ability to restrict the ADD right.

Now I think there is something not easy to understand. In the test case, the right to ADD is granted by this aci. But reading the resource filters (target, targetfilter and targetattrfilters) one of filter is not satisfied (targetattrfilters) and I would expect an AND operator for each resource filter. In that condition I would not expect this aci to be selected for that resource/entry.

Also if the aci was a DENY. I would expect that adding the entry is denied, if the entry contains this attribute value. But if the aci is selected, when the attribute does not exist, it makes the attribute as required with a "something different" value.

I think it could be a doc bug to better explain this corner case, but the usage of targetattrfilter is not easy to understand.

I think you're right that it is difficult to understand what all the target definitions do. But I don't think that it is an AND of all rules to targ3et an entry.
In my understanding we do target entries, attributes and attribute values.
For entries the target and target filter rules are applied, for attributes the targetattr rule and for values the targattrfilter rules.

So for an add operation and the given aci we first find that that target AND targetfilter rules apply and we have add right to the entry, now we still need write permission for all attributes, so it will check for each attribute toi be added if there is an attribute/attrvalue rule which restricts access otherwise assuming the implicte allow. But the entry doesn't have a member attr, so it will not be evaluated.

Thanks for your explanation. I understand now this restriction definition and why the aci is finally selected.

So I agree with you this is the expected behaviour, difficult to understand regarding aci syntax, but correct.

Metadata Update from @lkrispen:
- Issue set to the milestone: N/A

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/1015

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: Invalid)

Metadata