I'm sponsoring this fast-track on behalf of Vallish Vaidyeshwara (RPE).
This case seeks minor binding.
Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
This information is Copyright 2009 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
noaclfab share option
1.2. Name of Document Author/Supplier:
Author: Vallish Vaidyeshwara
1.3 Date of This Document:
04 December, 2009
4. Technical Description
When a file is created on a Solaris NFS client, the client requests the
"default ACL" on the directory in order to determine if the umask
should be applied or not (See: vn_createat() --> VOP_GETSECATTR()).
Previous to the integration of ZFS, we only supported Posix Draft ACLs
on the local file system (UFS).
Any time the NFSv2/v3/v4 client creates a file, it also requests the
ACL from the NFS server. If the underlying file system on the Solaris
NFS server doesn't support Posix-Draft style ACLs, then the server
simply "fabricates" an ACL based on the mode of the file.
Once ZFS was integrated, Solaris began supporting two distinct,
incompatible ACL formats on the local filesystems: Posix Draft ACLs
(on UFS) and NFSv4-style ACLs (on ZFS). Note that:
- ZFS supports NFSv4-style ACLs but does not support POSIX-Draft ACLs.
- UFS supports POSIX-Draft ACLs but does not support NFSv4-style ACLs.
- NFSv2/v3 supports POSIX-Draft ACLs but not NFSv4-style ACLs.
Since the Solaris NFSv2/v3 server cannot support the NFSv4-style ACL
format that ZFS uses, it fabricates a Posix Draft ACL and passes it
back to the v2/v3 client. In other words, if all of the following are
true:
- An ACL is requested by an NFS v2/v3 client
- The underlying file system on the server is ZFS
- An (NFSv4-style) ACL already exists on the file
Then the server will *still* fabricate a Posix-Draft ACL. This causes
the following problems as described by CR 6894228 (nfs v3/v2 should not
fabricate ACLs).
- The fabricated (Posix Draft) ACL may be very different from the
legitimate (NFSv4-style) ACL that exists on the server. Note that
the fabricated ACL it is based solely on the mode of the file which
can't represent all the information in the legitimate ACL.
- The user could retrieve the fabricated ACL on the client and attempt
to perform some operation only to be denied when the "real" ACL is
evaluated on the server.
Proposed Solution:
------------------
This case proposes a new NFS share option "noaclfab" to indicate that a
fabricated ACL should NOT be generated by the NFS server for this share
point. The "noaclfab" option is per share/export and the default
behavior is to continue fabricating ACLs on NFS servers where
underlying filesystems don't support Posix Draft ACLs. With this
approach, there is no risk of incompatibility with existing NFS
clients.
Steps to enable the fix:
------------------------
Filesystem has to be shared using "noaclfab" option. This is a per
share/export option and following example illustrates usage of
"noaclfab" option:
On server:
bash-3.2# sharemgr show -vp
default nfs=()
zfs
bash-3.2# sharemgr add-share -s /tank -d "noaclfab testing" default
bash-3.2# sharemgr set -P nfs -p anon=0 -p noaclfab=true default
bash-3.2# sharemgr show -vp
default nfs=(anon="0" noaclfab="true")
/tank "noaclfab testing"
zfs
On client:
<root># mount -F nfs -o vers=3 nfs-server:/tank /mnt
<root># getfacl /mnt/zfs-file
/mnt/zfs-file: Operation not supported on transport endpoint
Alternative solution considered:
--------------------------------
The original motivation to fabricate ACLs on the NFSv2/v3 server was
failure of vn_createat() on the client side. This has now been fixed
in Nevada, OpenSolaris, and Solaris 10 code.
http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/vnode.c#1349
The team considered patching this in Solaris 9 and and lower releases.
It is now very risky to make NFSv2/v3 servers to error out and return
ENOSYS to clients executing VOP_GETSECATTR OTW calls. We will have
older releases of Solaris clients fail if Server uses ZFS as underlying
file system. Moreover, there might be other vendors of NFS clients who
are now relying on this behavior of our NFS server. Hence the safest
approach of making this a share option.
Man page changes:
-----------------
"noaclfab" option needs to be documented in sharemgr(1M) and
share_nfs(1M) man pages. Both the man pages talk about NFS share
properties/options. Man page addendum will be as shown below:
noaclfab=boolean
Allows NFS servers to return fabricated ACLs to NFS clients if the
underlying filesystem doesn't support Posix Draft ACL. The default
behavior for NFS servers is to fabricate ACLs. If noaclfab is set
to TRUE, then the NFS server does not fabricate ACLs if the
underlying filesystem doesn't support Posix Draft ACL.
6. Resources and Schedule
6.4. Steering Committee requested information
6.4.1. Consolidation C-team Name:
ON
6.5. ARC review type: FastTrack
6.6. ARC Exposure: open
