SUMMARY: This proposal is to change the ZFS ACL inheritance rules when the zfs acl property is set to "passthrough". PROBLEM: The ZFS ACL subsystem provides a property aclinherit to control how ACL inheritance is performed. The default value "secure" creates ACLs that conform to POSIX access control semantics. Many customers desire native NFSv4 ACL inheritance. They want to be able to "force" the mode that files and directories are created with. In the past they would use default ACLs on UFS to achieve this. The NFSv4 ACL model can also do this, but the current implementation in ZFS disables the ACEs owner@, group@, and everyone@ in order to set the mode of the file to the mode the application requested. This problem has been discussed countless times on zfs-discuss@opensolaris.org and has caused some customers to not upgrade to ZFS because they need a way to force the creation mode for files and directories. The current behavior differs from UFS and is unintuitive to users and the zfs community consesus is that we should have a mechanism for inheriting permissions for ACEs that affect the mode of the file. PROPOSED SOLUTION: The aclinherit property already supports a "passthrough" value which is intended to provide a more native NFSv4 ACL representation, but today only allows an application to inherit the control permissions "write_owner and or write_acl". If we expand the meaning of this property, such that if a parent directory contains inheritable owner@, group@ or everyone@ ACEs then those permissions will replace the requested mode for the file or directory create. This will be similar to UFS default ACLs, except that the administrator will have to enable the capability on the file system via the aclinherit property. See below for an example of this. This behavior only affects the initial create of the file or directory. Subsequent chmod(2) requests will apply the chmod(2) algorithm that ZFS already uses to enforce POSIX semantics. ZFS already has other features that take us out of POSIX control. For example, the nbmand property, system attributes, such as readonly, immutable, nounlink, appendonly, quarantined, and so on. The default value "secure" is being renamed to "restricted", but an alias for "secure" will be provided for existing users. INHERITANCE EXAMPLES: First lets look at a UFS default ACL example For this example I will using user "sys" and "dladm" that are both in the "sys" group. # su sys # mkdir ufs-test # chmod 775 ufs-test Now lets create a default ACL that will specify 0666 for new files. # setfacl -m d:u::rw-,d:g::rw-,d:o:rw-,d:m:rwx ufs-test # ls -dV ufs-test drwxrwxr-x+ 2 sys sys 512 Mar 19 13:21 ufs-test 0:user::rwx 1:group::rwx #effective:rwx 2:mask:rwx 3:other:r-x 4:Default:user::rw- 5:default:group::rw- 6:default:mask:rwx 7:default:other:rw- Now switch to user dladm and create a new file and set our umask to 066. # su dladm dladm$ umask 066 dladm$ cd ufs-test dladm$ touch a dladm$ ls -l a # ls -l x -rw-rw-rw- 1 dladm sys 0 Mar 19 11:36 a The next example is what most users typical try to do with ZFS to achieve the same sort of thing. # mkdir dir1 Now lets prepend 3 ACEs to the beginning of the ACL on the directory for owner@, group@ and everyone@ that are specified to inherit to newly created files and directories. # mkdir /sandbox/dir1 # chmod 755 /sandbox/dir1 # chmod A+owner@:rw:fd:allow,group@:rw:fd:allow, \ everyone@:rw:fd:allow dir1 # ls -dV dir1 drwxrwxrwx+ 2 root root 3 Mar 19 13:04 dir1 owner@:rw------------:fd-----:allow group@:rw------------:fd-----:allow everyone@:rw------------:fd-----:allow owner@:--------------:-------:deny owner@:rwxp---A-W-Co-:-------:allow group@:rw-p----------:-------:deny group@:--x-----------:-------:allow everyone@:rw-p---A-W-Co-:-------:deny everyone@:--x---a-R-c--s:-------:allow # cd dir1 # touch a Now lets look at the new file. # ls -V a -rw-r--r--+ 1 root root 0 Mar 19 13:04 a owner@:--------------:------I:allow group@:--------------:------I:allow everyone@:--------------:------I:allow owner@:--x-----------:-------:deny owner@:rw-p---A-W-Co-:-------:allow group@:-wxp----------:-------:deny group@:r-------------:-------:allow everyone@:-wxp---A-W-Co-:-------:deny everyone@:r-----a-R-c--s:-------:allow What happens here is that ZFS inherited the 3 ACEs (owner@, group@, everyone@) as indicated by the ------I, but then they were disabled in order to place POSIX semantics on the file and also to set the mode to 0644. The customer was expecting the file to be created with mode 0666. The remaining examples are with the proposed solution to allow inheriting mode bit permissions. # zfs create sandbox/testfs Now lets set the passthrough mode for aclinherit # zfs set aclinherit=passthrough sandbox/testfs # cd /sandbox/testfs # mkdir testdir Now lets set up an ACL on testdir to cause inheritance. This will create a 3 member ACL for newly created files. It will have one owner@, group@, and everyone@ entry. Newly created Directories will have 3 entries for @owner@, group@, and everyone@. Additionally, directories will have 6 other ACEs which are for propagating the ACEs to newly created directories and files. # chmod A+owner@:rwxpAWC:d:allow,owner@:rwpAWC:f, \ group@:x:d:allow,group@::f:allow,everyone@:x:d, \ everyone@::f:allow testdir First lets create a file. # cd testdir # touch file.1 # ls -V file.1 -rw-------+ 1 root root 0 Mar 18 10:49 file.1 owner@:rw-p---A-W-C--:------I:allow group@:--------------:------I:allow everyone@:--------------:------I:allow This created an ACL with just the three ACEs that were specified to be inherited to newly created files. Now lets create a directory. The inherited ACL will include both ACEs that control access to this directory as well as ACEs for future propagation to children of the newly created directory. # mkdir dir.1 # ls -dV dir.1 drwx--x--x+ 2 root root 2 Mar 18 10:51 dir.1 owner@:rwxp---A-W-C--:-di---I:allow owner@:rwxp---A-W-C--:------I:allow owner@:rw-p---A-W-C--:f-i---I:allow group@:--x-----------:-di---I:allow group@:--x-----------:------I:allow group@:--------------:f-i---I:allow everyone@:--x-----------:-di---I:allow everyone@:--x-----------:------I:allow everyone@:--------------:f-i---I:allow The entries with -di-- and f-i--- are for propagating and are not considered during access control. Now lets move to another directory where inherited ACEs aren't present and the file will be created with a trivial ACL. # cd /sandbox/testfs # touch file.1 # ls -V file.1 -rw-r--r-- 1 root root 0 Mar 18 10:53 file.1 owner@:--x-----------:-------:deny owner@:rw-p---A-W-Co-:-------:allow group@:-wxp----------:-------:deny group@:r-------------:-------:allow everyone@:-wxp---A-W-Co-:-------:deny everyone@:r-----a-R-c--s:-------:allow RELEASE BINDING Patch/Micro - Change will need to be backported to Solaris 10. No change to existing ACL interface stability levels. MANPAGE DIFFS 539c539 < aclinherit=discard | noallow | restricted | passthrough --- > aclinherit=discard | noallow | secure | passthrough 547c547 < "restricted" (the default) removes the "write_acl" and --- > "secure" (the default) removes the "write_acl" and 554,558d553 < When property value is set to "passthrough" files will be < created with a mode determined by the inheritable ACEs. < If no inheritable ACEs exist that affect the mode then < the mode will be set in accordance to the requested mode < from the application. 560d554 < 2295c2289 < pool/home/bob aclinherit restricted default --- > pool/home/bob aclinherit secure default