OpenZFS 6765 - zfs_zaccess_delete() comments do not accurately

reflect delete permissions for ACLs

Authored by: Kevin Crowe <kevin.crowe@nexenta.com>
Reviewed by: Gordon Ross <gwr@nexenta.com>
Reviewed by: Yuri Pankov <yuri.pankov@nexenta.com>
Reviewed by: Brian Behlendorf <behlendorf1@llnl.gov>
Approved by: Richard Lowe <richlowe@richlowe.net>
Ported-by: Paul B. Henson <henson@acm.org>

Porting Notes:
* Only comments are updated

OpenZFS-issue: https://www.illumos.org/issues/6765
OpenZFS-commit: https://github.com/openzfs/openzfs/commit/da412744bc
Closes #10266
This commit is contained in:
Paul B. Henson 2019-12-06 05:35:38 +00:00 committed by Brian Behlendorf
parent 235a856576
commit 0aeb0bed6f

View File

@ -2687,8 +2687,10 @@ int zfs_write_implies_delete_child = 1;
/* /*
* Determine whether delete access should be granted. * Determine whether delete access should be granted.
* *
* The following chart is the recommended NFSv4 enforcement for * The following chart outlines how we handle delete permissions which is
* ability to delete an object. * how recent versions of windows (Windows 2008) handles it. The efficiency
* comes from not having to check the parent ACL where the object itself grants
* delete:
* *
* ------------------------------------------------------- * -------------------------------------------------------
* | Parent Dir | Target Object Permissions | * | Parent Dir | Target Object Permissions |
@ -2697,14 +2699,14 @@ int zfs_write_implies_delete_child = 1;
* | | ACL Allows | ACL Denies| Delete | * | | ACL Allows | ACL Denies| Delete |
* | | Delete | Delete | unspecified| * | | Delete | Delete | unspecified|
* ------------------------------------------------------- * -------------------------------------------------------
* | ACL Allows | Permit | Permit * | Permit | * | ACL Allows | Permit | Deny * | Permit |
* | DELETE_CHILD | | | | * | DELETE_CHILD | | | |
* ------------------------------------------------------- * -------------------------------------------------------
* | ACL Denies | Permit * | Deny | Deny | * | ACL Denies | Permit | Deny | Deny |
* | DELETE_CHILD | | | | * | DELETE_CHILD | | | |
* ------------------------------------------------------- * -------------------------------------------------------
* | ACL specifies | | | | * | ACL specifies | | | |
* | only allow | Permit | Permit * | Permit | * | only allow | Permit | Deny * | Permit |
* | write and | | | | * | write and | | | |
* | execute | | | | * | execute | | | |
* ------------------------------------------------------- * -------------------------------------------------------
@ -2717,24 +2719,21 @@ int zfs_write_implies_delete_child = 1;
* Re. execute permission on the directory: if that's missing, * Re. execute permission on the directory: if that's missing,
* the vnode lookup of the target will fail before we get here. * the vnode lookup of the target will fail before we get here.
* *
* Re [*] in the table above: We are intentionally disregarding the * Re [*] in the table above: NFSv4 would normally Permit delete for
* NFSv4 committee recommendation for these three cells of the matrix * these two cells of the matrix.
* because that recommendation conflicts with the behavior expected * See acl.h for notes on which ACE_... flags should be checked for which
* by Windows clients for ACL evaluation. See acl.h for notes on * operations. Specifically, the NFSv4 committee recommendation is in
* which ACE_... flags should be checked for which operations. * conflict with the Windows interpretation of DENY ACEs, where DENY ACEs
* Specifically, the NFSv4 committee recommendation is in conflict
* with the Windows interpretation of DENY ACEs, where DENY ACEs
* should take precedence ahead of ALLOW ACEs. * should take precedence ahead of ALLOW ACEs.
* *
* This implementation takes a conservative approach by checking for * This implementation always consults the target object's ACL first.
* DENY ACEs on both the target object and it's container; checking * If a DENY ACE is present on the target object that specifies ACE_DELETE,
* the ACE_DELETE on the target object, and ACE_DELETE_CHILD on the * delete access is denied. If an ALLOW ACE with ACE_DELETE is present on
* container. If a DENY ACE is found for either of those, delete * the target object, access is allowed. If and only if no entries with
* access is denied. (Note that DENY ACEs are very rare.) * ACE_DELETE are present in the object's ACL, check the container's ACL
* for entries with ACE_DELETE_CHILD.
* *
* Note that after these changes, entire the second row and the * A summary of the logic implemented from the table above is as follows:
* entire middle column of the table above change to Deny.
* Accordingly, the logic here is somewhat simplified.
* *
* First check for DENY ACEs that apply. * First check for DENY ACEs that apply.
* If either target or container has a deny, EACCES. * If either target or container has a deny, EACCES.