From rsb@sac.sfbay.sun.com Fri Dec 4 12:36:46 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB4Kak1p024215 for ; Fri, 4 Dec 2009 12:36:46 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB4KakB1015152; Fri, 4 Dec 2009 12:36:46 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KU500D01ALAQC00@nwk-avmta-2.sfbay.sun.com>; Fri, 04 Dec 2009 12:36:46 -0800 (PST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KU500D2QAL9O100@nwk-avmta-2.sfbay.sun.com>; Fri, 04 Dec 2009 12:36:45 -0800 (PST) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB4Kah5h006860; Fri, 04 Dec 2009 12:36:43 -0800 (PST) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB4Kag2B024210; Fri, 04 Dec 2009 12:36:42 -0800 (PST) Received: (from rsb@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id nB4Kag36024206; Fri, 04 Dec 2009 14:36:42 -0600 (CST) Date: Fri, 04 Dec 2009 14:36:42 -0600 (CST) From: Rich.Brown@sun.com Subject: noaclfab share option [PSARC/2009/661 FastTrack timeout 12/11/2009] To: PSARC-ext@sun.com Cc: Rich.Brown@sun.com, lisa.week@sun.com, vallish.vaidyeshwara@sun.com Message-id: <200912042036.nB4Kag36024206@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 5052 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: # mount -F nfs -o vers=3 nfs-server:/tank /mnt # 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 From gww@sac.sfbay.sun.com Mon Dec 7 11:54:54 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB7JssjN029830 for ; Mon, 7 Dec 2009 11:54:54 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB7JsrTo002944 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 7 Dec 2009 11:54:53 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KUA00F0NSNHY400@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 07 Dec 2009 11:54:53 -0800 (PST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KUA00CLSSNHTQ50@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 07 Dec 2009 11:54:53 -0800 (PST) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB7JsoDf012489; Mon, 07 Dec 2009 11:54:50 -0800 (PST) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB7JsomD029827; Mon, 07 Dec 2009 11:54:50 -0800 (PST) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id nB7JsoO4029826; Mon, 07 Dec 2009 11:54:50 -0800 (PST) Date: Mon, 07 Dec 2009 11:54:50 -0800 (PST) From: Gary Winiger Subject: Re: noaclfab share option [PSARC/2009/661 FastTrack timeout 12/11/2009] To: PSARC-ext@sun.com, Rich.Brown@sun.com Cc: lisa.week@sun.com, vallish.vaidyeshwara@sun.com Message-id: <200912071954.nB7JsoO4029826@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 235 > I'm sponsoring this fast-track on behalf of Vallish Vaidyeshwara (RPE). > This case seeks minor binding. Is this really only needed in Solaris Next? It seems OK to me for a Patch binding if needed. +1 for either binding. Gary.. From Vallish.Vaidyeshwara@sun.com Mon Dec 7 22:52:10 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB86qA9b015983 for ; Mon, 7 Dec 2009 22:52:10 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB86q9di018409 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 7 Dec 2009 22:52:10 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KUB00G0FN2YGW00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 07 Dec 2009 23:52:10 -0700 (MST) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KUB00C89N2V5P20@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 07 Dec 2009 23:52:08 -0700 (MST) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nB86q64Y022834 for ; Tue, 08 Dec 2009 06:52:06 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KUB00M00MZJIJ00@mail-apac.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 08 Dec 2009 14:52:06 +0800 (SGT) Received: from [129.158.212.182] ([unknown] [129.158.212.182]) by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KUB008KHN2UK3G0@mail-apac.sun.com>; Tue, 08 Dec 2009 14:52:06 +0800 (SGT) Date: Tue, 08 Dec 2009 13:06:31 +0530 From: Vallish Vaidyeshwara Subject: Re: noaclfab share option [PSARC/2009/661 FastTrack timeout 12/11/2009] In-reply-to: <200912071954.nB7JsoO4029826@sac.sfbay.sun.com> Sender: Vallish.Vaidyeshwara@sun.com To: Gary Winiger Cc: PSARC-ext@sun.com, Rich.Brown@sun.com, Lisa.Week@sun.com Message-id: <4B1E01FF.4010502@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200912071954.nB7JsoO4029826@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080129) Status: RO Content-Length: 470 Gary Winiger wrote: >> I'm sponsoring this fast-track on behalf of Vallish Vaidyeshwara (RPE). >> This case seeks minor binding. >> > > Is this really only needed in Solaris Next? It seems OK to me > for a Patch binding if needed. > +1 for either binding. > > Gary.. > Hi Gary, This bug is an Amber Road requirement and I intent to make these changes only in nevada. If required in future, I will backport these changes to lower releases. Thanks. -Vallish From Rich.Brown@Sun.COM Tue Dec 8 09:15:08 2009 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB8HF8Zg011358 for ; Tue, 8 Dec 2009 09:15:08 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB8HF5Pl017419 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 8 Dec 2009 11:15:07 -0600 (CST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KUC00A0LFX6XE00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 08 Dec 2009 10:15:06 -0700 (MST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KUC00I3KFX66YF0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 08 Dec 2009 10:15:06 -0700 (MST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nB8HF5i2020006 for ; Tue, 08 Dec 2009 17:15:06 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KUC00900FHFWJ00@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 08 Dec 2009 10:15:05 -0700 (MST) Received: from [129.147.9.136] ([unknown] [129.147.9.136]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KUC004S5FX3N730@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 08 Dec 2009 10:15:04 -0700 (MST) Date: Tue, 08 Dec 2009 11:15:03 -0600 From: Rich Brown Subject: Re: noaclfab share option [PSARC/2009/661 FastTrack timeout 12/11/2009] In-reply-to: <4B1E01FF.4010502@Sun.COM> Sender: Rich.Brown@Sun.COM To: PSARC-ext@Sun.COM Cc: Vallish Vaidyeshwara , Lisa.Week@Sun.COM Message-id: <4B1E8997.7080600@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200912071954.nB7JsoO4029826@sac.sfbay.sun.com> <4B1E01FF.4010502@Sun.COM> User-Agent: Thunderbird 2.0.0.23 (X11/20090910) Status: RO Content-Length: 867 Originally, I asked for "minor" binding since there was no current plan to do a backport. Given Gary's suggestion and since the possibility exists that a customer may need this backported, I'd like to change the binding to: micro/patch. Please let me know if anyone has an issue with that change. Thanks! Rich On 12/08/09 01:36, Vallish Vaidyeshwara wrote: > Gary Winiger wrote: >>> I'm sponsoring this fast-track on behalf of Vallish Vaidyeshwara (RPE). >>> This case seeks minor binding. >>> >> >> Is this really only needed in Solaris Next? It seems OK to me >> for a Patch binding if needed. >> +1 for either binding. >> >> Gary.. >> > Hi Gary, > > This bug is an Amber Road requirement and I intent to make these changes > only in nevada. > If required in future, I will backport these changes to lower releases. > > Thanks. > -Vallish From glenn.skinner@covad.net Tue Dec 8 14:14:30 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB8METxe020328 for ; Tue, 8 Dec 2009 14:14:29 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB8MEQKC008155; Tue, 8 Dec 2009 14:14:27 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KUC00K1NTS2KS00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 08 Dec 2009 14:14:26 -0800 (PST) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KUC00IVUTS1A540@nwk-avmta-1.sfbay.Sun.COM>; Tue, 08 Dec 2009 14:14:25 -0800 (PST) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nB8M9ZmQ002188; Tue, 08 Dec 2009 22:14:25 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay15i.sun.com with ESMTP id BT-MMP-4192714; Tue, 08 Dec 2009 22:14:24 +0000 (Z) Received: from relay11i.sun.com (relay11i.sun.com [129.179.4.121]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-116184403; Tue, 08 Dec 2009 22:14:24 +0000 (Z) Received: from mail155c8.megamailservers.com ([209.235.129.65] [209.235.129.65]) by relay1i.sun.com with ESMTP id BT-MMP-20684955; Tue, 08 Dec 2009 22:14:24 +0000 (Z) Received: from [192.168.1.106] (h-64-105-36-23.snvacaid.static.covad.net [64.105.36.23]) by mail155c8.megamailservers.com (8.13.6/8.13.1) with ESMTP id nB8MDpNs001666; Tue, 08 Dec 2009 17:14:23 -0500 Date: Tue, 08 Dec 2009 14:13:51 -0800 From: Glenn Skinner Subject: Re: 2009/661 [noaclfab share option] In-reply-to: <200912042036.nB4Kag36024206@sac.sfbay.sun.com> To: Rich.Brown@sun.com Cc: PSARC-ext@sun.com, vallish.vaidyeshwara@sun.com, lisa.week@sun.com Message-id: <48FE84AB-E09A-4B7A-B406-37A75C9F4DF3@covad.net> MIME-version: 1.0 X-Mailer: Apple Mail (2.936) Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-POP-User: gcskinner.covad.net References: <200912042036.nB4Kag36024206@sac.sfbay.sun.com> Status: RO Content-Length: 4454 On Dec 4, 2009, at 12:36 PM, Rich.Brown@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 From Vallish.Vaidyeshwara@sun.com Wed Dec 9 04:08:48 2009 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB9C8mLZ018644 for ; Wed, 9 Dec 2009 04:08:48 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB9C8NZ9011531 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 9 Dec 2009 06:08:24 -0600 (CST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KUD00E0FWDZSW00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Dec 2009 04:08:23 -0800 (PST) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KUD00FJLWDYPVD0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Dec 2009 04:08:23 -0800 (PST) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nB9C8L0I017534 for ; Wed, 09 Dec 2009 12:08:21 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KUD00G00W3YD100@mail-apac.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Dec 2009 20:08:21 +0800 (SGT) Received: from [129.158.212.182] ([unknown] [129.158.212.182]) by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KUD00MDNWDX0SD0@mail-apac.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Dec 2009 20:08:21 +0800 (SGT) Date: Wed, 09 Dec 2009 17:38:50 +0530 From: Vallish Vaidyeshwara Subject: Re: 2009/661 [noaclfab share option] In-reply-to: <48FE84AB-E09A-4B7A-B406-37A75C9F4DF3@covad.net> Sender: Vallish.Vaidyeshwara@sun.com To: Glenn Skinner Cc: Rich.Brown@sun.com, PSARC-ext@sun.com, Lisa.Week@sun.com Message-id: <4B1F9352.1090308@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200912042036.nB4Kag36024206@sac.sfbay.sun.com> <48FE84AB-E09A-4B7A-B406-37A75C9F4DF3@covad.net> User-Agent: Thunderbird 2.0.0.23 (X11/20090929) Status: RO Content-Length: 2137 >> >> >> - 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. > Hi Glenn, Problem with returning an error from NFSv2/v3 servers without doing an ACL fabrication was resulting in vn_createat() to fail on client. ACL fabrication was introduced in NFSv2/v3 server to fix this problem on client. This was the real intent of fabricating ACLs in the first place. Problem of vn_createat() failing has now been fixed in nevada and Solaris 10 code. http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/vnode.c#1349 With this fix on client side, ACL fabrication has become redundant on Server. However, the fix on Client has not been backported to Solaris 9 and lower releases. We will have older versions of Solaris client fail if ACL fabrication code on server is removed. More over other NFS vendors might now be relying on this behavior and removing ACL fabrication will make interoperability fail. The best would have been to remove ACL fabrications completely, but for reasons stated above this is going to be risky. Hence the safest approach of making this a share option. Improving ACL fabrication and making it do a better job of approximating NFSv4 ACL, will still have the following problem: >> >> - 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. Thanks. -Vallish From gww@eng.sun.com Wed Dec 9 14:10:30 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB9MAUjD005108 for ; Wed, 9 Dec 2009 14:10:30 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB9MAU52021867 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 9 Dec 2009 14:10:30 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KUE00H01O9IAB00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Dec 2009 14:10:30 -0800 (PST) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KUE0010MO9IXF80@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Dec 2009 14:10:30 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB9MAQpf013395; Wed, 09 Dec 2009 14:10:26 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id nB9M9b5L002120; Wed, 09 Dec 2009 14:09:37 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id nB9M9aKE002119; Wed, 09 Dec 2009 14:09:36 -0800 (PST) Date: Wed, 09 Dec 2009 14:09:36 -0800 (PST) From: Gary Winiger Subject: Re: 2009/661 [noaclfab share option] To: glenn.skinner@covad.net, Vallish.Vaidyeshwara@sun.com Cc: Rich.Brown@sun.com, PSARC-ext@sun.com, Lisa.Week@sun.com Message-id: <200912092209.nB9M9aKE002119@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 582 > Improving ACL fabrication and making it do a better job of approximating > NFSv4 ACL, will still have the following problem: > > >> > >> - 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. This was my compelling reason for not doing my normal, I hate configuration options, please fix it so ACL fabrication works. IMO, it can't be reasonably fixed because ACL/ACE are different. That's something we/the ARC accepted in the ZFS and NFSv4 cases. Gary.. From glenn.skinner@covad.net Wed Dec 9 23:15:37 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBA7FaiY015598 for ; Wed, 9 Dec 2009 23:15:36 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nBA7FTec019232; Wed, 9 Dec 2009 23:15:29 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KUF00E01DHTL800@nwk-avmta-2.sfbay.sun.com>; Wed, 09 Dec 2009 23:15:29 -0800 (PST) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KUF009R5DHTE930@nwk-avmta-2.sfbay.sun.com>; Wed, 09 Dec 2009 23:15:29 -0800 (PST) Received: from relay11i.sun.com (ip121.net129179-4.block1.us.syntegra.com [129.179.4.121]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nBA78jBg011977; Thu, 10 Dec 2009 07:15:29 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay11i.sun.com with ESMTP id BT-MMP-8600085; Thu, 10 Dec 2009 07:15:29 +0000 (Z) Received: from relay11i.sun.com (relay11i.sun.com [129.179.4.121]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-118709595; Thu, 10 Dec 2009 07:15:28 +0000 (Z) Received: from mail155c8.megamailservers.com ([209.235.129.65] [209.235.129.65]) by relay1i.sun.com with ESMTP id BT-MMP-23480344; Thu, 10 Dec 2009 07:15:28 +0000 (Z) Received: from [192.168.1.106] (h-64-105-36-23.snvacaid.static.covad.net [64.105.36.23]) by mail155c8.megamailservers.com (8.13.6/8.13.1) with ESMTP id nBA7EuJx029943; Thu, 10 Dec 2009 02:15:27 -0500 Date: Wed, 09 Dec 2009 23:14:55 -0800 From: Glenn Skinner Subject: Re: 2009/661 [noaclfab share option] In-reply-to: <200912092209.nB9M9aKE002119@marduk.eng.sun.com> To: Gary Winiger Cc: Vallish.Vaidyeshwara@sun.com, Rich.Brown@sun.com, PSARC-ext@sun.com, Lisa.Week@sun.com Message-id: <6EBF0FD5-7BF3-4B47-8A25-661FBC3C4C7C@covad.net> MIME-version: 1.0 X-Mailer: Apple Mail (2.936) Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-POP-User: dbclispr.covad.net References: <200912092209.nB9M9aKE002119@marduk.eng.sun.com> Status: RO Content-Length: 732 On Dec 9, 2009, at 2:09 PM, Gary Winiger wrote: >> Improving ACL fabrication and making it do a better job of >> approximating >> NFSv4 ACL, will still have the following problem: >> >>>> >>>> - 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. > > This was my compelling reason for not doing my normal, I hate > configuration options, please fix it so ACL fabrication works. > IMO, it can't be reasonably fixed because ACL/ACE are different. > That's something we/the ARC accepted in the ZFS and NFSv4 cases. After thinking about it some more, I reluctantly agree. +1 to the case. -- Glenn From Rich.Brown@sun.com Fri Dec 11 11:43:29 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBBJhTRv029028 for ; Fri, 11 Dec 2009 11:43:29 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id nBBJhRYw007597 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 11 Dec 2009 12:43:28 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KUI00E1X6SGI800@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Fri, 11 Dec 2009 11:43:28 -0800 (PST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KUI0044E6SF3FA0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Fri, 11 Dec 2009 11:43:27 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nBBJhRld024745 for ; Fri, 11 Dec 2009 19:43:27 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KUI00F006KW2800@mail-amer.sun.com> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Fri, 11 Dec 2009 12:43:27 -0700 (MST) Received: from [129.147.9.136] ([unknown] [129.147.9.136]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KUI00JBS6SA7NA0@mail-amer.sun.com> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Fri, 11 Dec 2009 12:43:23 -0700 (MST) Date: Fri, 11 Dec 2009 13:43:22 -0600 From: Rich Brown Subject: Re: noaclfab share option [PSARC/2009/661 FastTrack timeout 12/11/2009] In-reply-to: <200912042036.nB4Kag36024206@sac.sfbay.sun.com> Sender: Rich.Brown@sun.com To: PSARC-ext@sun.com Cc: Lisa.Week@sun.com, Vallish.Vaidyeshwara@sun.com Message-id: <4B22A0DA.3000608@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200912042036.nB4Kag36024206@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20090910) Status: RO Content-Length: 5702 The timer has expired, the discussion has converged, and this case has two "+1"s from the two ARC members who participated in the discussion. Also, I had upgraded the binding to "patch" with explicit approval from Gary and saw no objections. Thank you all for your time and participation. I'm marking this case as "approved". Rich On 12/04/09 14:36, Rich.Brown@Sun.COM wrote: > 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: > > # mount -F nfs -o vers=3 nfs-server:/tank /mnt > # 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 >