On Dec 4, 2009, at 12:36 PM, Rich.Brown at sun.com wrote: > I'm sponsoring this fast-track on behalf of Vallish Vaidyeshwara > (RPE). > This case seeks minor binding.
After reading the solution proposed below, it seems to me that we've been reduced to throwing up our collective hands on the problem. Is there no way to do a better job of handling it? (See below for additional interleaved comments.) ... > 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. Could the fabrication technique be changed to take the NFSv4 ACL into account? The resulting POSIX-Draft ACL could potentially be a much better approximation of the original. In many cases, they would have identical semantics. One question to investigate is how frequent and severe the mismatch cases are. A possibility the proposal doesn't mention is trying to fabricate a semantically equivalent ACL and forcing the request to fail only when that's not possible. > > - 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. ... > 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. I gave a couple suggestions above. I suspect there are other alternatives that haven't occurred to me. But my basic question remains: Can we do better than what's proposed here? -- Glenn
