I think the aci:

{{{
aci: (targetattr = "mail") (version 3.0;acl "allow write of mail";allow
(all)(userdn = "ldap:///uid=user878,ou=people,o=redhat");)
}}}

Grants all rights to any entry having 'mail'. So I wonder if it is not an expected behavior it grants delete rights as the resource contains mail

Replying to [comment:3 tbordaz]:

I think the aci:

{{{
aci: (targetattr = "mail") (version 3.0;acl "allow write of mail";allow
(all)(userdn = "ldap:///uid=user878,ou=people,o=redhat");)
}}}

Grants all rights to any entry having 'mail'. So I wonder if it is not an expected behavior it grants delete rights as the resource contains mail

Hmmm. But aren't these contradictory to it?

1) ldapsearch returns only if the search filter is about "mail" and it only returns the mail attribute value...
{{{
$ ldapsearch ... -D 'uid=tuser777,ou=People,dc=example,dc=com' -W -b "dc=example,dc=com" "(mail=777)"
dn: uid=atest,ou=People,dc=example,dc=com
mail: new777@example.com
}}}

2) move/ldapmodify the entry fails with Insufficient access.
{{{
modifying rdn of entry "uid=atest,ou=People,dc=example,dc=com"
ldap_rename: Insufficient access (50)
}}}

3) And you cannot add/modify/delete any other attributes, but you can delete the entry itself...

Why just deleting the entry is allowed...?

I agree with your update (https://fedorahosted.org/389/ticket/49078#comment:5), it looks strange that among all rights, only DEL entry and add/mod/del on 'mail' are granted.

It is looking like 'plugin_call_acl_plugin' (ldbm_delete) calls aci evaluation without any attribute.
Also showed in

{{{
[28/Dec/2016:10:41:45 +0100] NSACLPlugin - ** RESOURCE INFO
STARTS *
[28/Dec/2016:10:41:45 +0100] NSACLPlugin - Client DN:
uid=user878,ou=people,o=redhat
[28/Dec/2016:10:41:45 +0100] NSACLPlugin - resource type:256(delete
target_DN )
[28/Dec/2016:10:41:45 +0100] NSACLPlugin - Slapi_Entry DN:
cn=user44,ou=people,o=redhat
[28/Dec/2016:10:41:45 +0100] NSACLPlugin - ATTR: NULL
[28/Dec/2016:10:41:45 +0100] NSACLPlugin - rights:delete
[28/Dec/2016:10:41:45 +0100] NSACLPlugin - ** RESOURCE INFO ENDS

}}}

So I wonder if deletion of the entry does not require any rights on any attribute and as a consequence DEL is granted.
In the opposite, MODRDN, MOD impacts attributes and it updates attributes not listed in 'targetattr' then the aci is not selected.

The RC should be easy to identified with the perfect testcase

I think the behaviour is as designed. In the aci you target entries and attributes, so if you do not use any specific target rule or target filter the entres below the aci are targeted - and then aci evaluation looks for the rights needed: entry level or attribute level rights.

In the admin guide it says in 13.3.3.3:
Deleting an entry:

Grant delete permission on the entry to be deleted.
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.

and the same for adds.

if you want to change behaviour you should replace "all" by the desired rights

Replying to [comment:8 lkrispen]:

I think the behaviour is as designed. In the aci you target entries and attributes, so if you do not use any specific target rule or target filter the entres below the aci are targeted - and then aci evaluation looks for the rights needed: entry level or attribute level rights.

In the admin guide it says in 13.3.3.3:
Deleting an entry:

Grant delete permission on the entry to be deleted.
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.

and the same for adds.

if you want to change behaviour you should replace "all" by the desired rights

I'm a bit confused... If we replace "all" with "compare,search,read,write,add,delete" as follows, the entry is still deleted by the account "uid=user878,ou=people,o=redhat". If you want to allow the account to do anything on the attribute "mail", but deny to delete the entry, how this aci should be modified?
{{{
aci: (targetattr = "mail") (version 3.0;acl "allow write of
mail";allow(compare,search,read,write,add,delete)(userdn =
"ldap:///uid=user878,ou=people,o=redhat");)
}}}
Thanks!

From my tests, we need to include the "write" right and remove "delete".

the attribute will be modified but the entry cannot be deleted.

Replying to [comment:11 gparente]:

From my tests, we need to include the "write" right and remove "delete".

the attribute will be modified but the entry cannot be deleted.

This is correct. The "add" and "delete" rights apply to entries, the add,delete,modify of an attribute is controlled by the "write" right

Closing this ticket along with the original bug.

https://bugzilla.redhat.com/show_bug.cgi?id=1408938#c9
{{{
Thank you for your comments and testing, Ludwig and German! (Sorry about my confusion.)

Both of you are 100% correct. The Administration Guide clearly describes it.

https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10.1/html/Administration_Guide/Managing_Access_Control-Creating_ACIs_Manually.html#Creating_ACIs_Manually-The_ACI_Syntax

Table 13.2. User Rights
Write - Indicates whether users can modify an entry by adding, modifying, or deleting attributes. This permission applies to the modify and modrdn operations.
Delete - Indicates whether users can delete an entry. This permission applies only to the delete operation.

Closing this bug as NOTABUG.
}}}

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

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.