Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready
Andreas Gruenbacher <agruen@suse.de> Tue, 11 July 2006 00:04 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G05jr-0002Gz-8P; Mon, 10 Jul 2006 20:04:31 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G05jp-0002Gu-JQ for nfsv4@ietf.org; Mon, 10 Jul 2006 20:04:29 -0400
Received: from mail.suse.de ([195.135.220.2] helo=mx1.suse.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G05jo-0008Bd-4j for nfsv4@ietf.org; Mon, 10 Jul 2006 20:04:29 -0400
Received: from Relay1.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id 14F0AEFE8; Tue, 11 Jul 2006 02:04:25 +0200 (CEST)
From: Andreas Gruenbacher <agruen@suse.de>
Organization: Novell / SUSE Labs
To: nfsv4@ietf.org
Subject: Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready
Date: Tue, 11 Jul 2006 02:01:42 +0200
User-Agent: KMail/1.9.1
References: <200607032310.15252.agruen@suse.de> <B0F5507F-A317-44F7-B6A3-A5005542A631@Sun.COM> <20060710141541.GA978@fieldses.org>
In-Reply-To: <20060710141541.GA978@fieldses.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200607110201.43319.agruen@suse.de>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5
Cc: Sam Falkner <Sam.Falkner@sun.com>, Lisa Week <Lisa.Week@sun.com>, "J. Bruce Fields" <bfields@fieldses.org>, nfs@lists.sourceforge.net, Spencer Shepler <spencer.shepler@sun.com>, Brian Pawlowski <beepy@netapp.com>
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/nfsv4>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
Errors-To: nfsv4-bounces@ietf.org
On Monday, 10. July 2006 16:15, J. Bruce Fields wrote: > On Mon, Jul 10, 2006 at 07:29:56AM -0600, Sam Falkner wrote: > > On Jul 9, 2006, at 10:22 AM, Andreas Gruenbacher wrote: > > >According to section 5.1 of draft-ietf-nfsv4-acls [1], the > > >resulting file mode > > >permission bits for this acl shall be rw-r--r--. > > > > Your proposal would give this mode: rw-rw-r--. I think we should > > consider this more carefully. > > As Andreas says, this is what the posix draft would have you do. It's > also what Linux (and, I assume, Solaris) do in the case of posix ACLs. We are not talking about the POSIX 1003.1e draft here, we are talking about the real POSIX standard. > If the goals was compatibility with that posix draft, RFC3530 should > have specified that owner, other, and group bits be kept in sync with > (respectively) OWNER@, EVERYONE@, and the *maximum* of permissions given > to any other entity, rather than with OWNER@, EVERYONE@, and GROUP@. I argued why I think this is a misbelief, please scan for well-formed ACLs and non-monotonic permissions. > > You would call it wrong that a chmod 770 would allow WRITE_DATA to > > members of the file's owning group?! The user did a chmod -- the > > user changed the permissions on the file! > > That is how posix acl's work; again, the group mode bit really > corresponds to the mask, not to the group acl entry: > > bfields@pickle:~$ getfacl foo > # file: foo > # owner: bfields > # group: bfields > user::rw- > user:bfields:r-- > group::r-- > mask::r-- > other::--- > > bfields@pickle:~$ chmod 770 foo > bfields@pickle:~$ getfacl foo > # file: foo > # owner: bfields > # group: bfields > user::rwx > user:bfields:r-- > group::r-- > mask::rwx > other::--- > > > Of course, "posix" acls aren't really posix, and we could do something > else if seems simpler. Neither behavior seems intuitive to me in all > situations. The issue is that you sometimes want to give the owning group fewer perissions than say, user:bfields in the above example. You can only do that by separating the owning group and mask permissions. For this aspect of the problem (actually for all aspects except for those that the DENY entries cause because they are sometimes difficult or impossible to uniquely tell from other "ordinary" entries) it is totally irrelevant whether the mask is represented as a mask:: acl entry as in POSIX ACLs, as a series of DENY ACL entries, or as NFSv4 attributes. (POSIX ACLs only need one mask entry because they can never grant more than rwx permissions anyway, and so the owner and other permissions are always identical to the owner and other file mode permission bits. That's no longer true with POSIX ACLs, and so there we also need mask entries for the owner and for others.) Andreas -- Andreas Gruenbacher <agruen@suse.de> Novell / SUSE Labs _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4
- [nfsv4] NFSv4 ACL and POSIX interaction / mask Andreas Gruenbacher
- [nfsv4] Re: NFSv4 ACL and POSIX interaction / mas… Andreas Gruenbacher
- [nfsv4] Re: NFSv4 ACL and POSIX interaction / mas… Sam Falkner
- Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction /… Sam Falkner
- Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction /… Andreas Gruenbacher
- Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction /… Lisa Week
- [nfsv4] Re: NFSv4 ACL and POSIX interaction / mask David Collier-Brown
- Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction /… Sam Falkner
- Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction /… J. Bruce Fields
- Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction /… Sam Falkner
- Re: [NFS] [nfsv4] Re: NFSv4 ACL and POSIX interac… J. Bruce Fields
- Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction /… Andreas Gruenbacher
- Re: [NFS] [nfsv4] Re: NFSv4 ACL and POSIX interac… Sam Falkner
- Re: [NFS] [nfsv4] Re: NFSv4 ACL and POSIX interac… J. Bruce Fields
- Re: [NFS] [nfsv4] Re: NFSv4 ACL and POSIX interac… J. Bruce Fields
- Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction /… Andreas Gruenbacher
- Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction /… Andreas Gruenbacher
- Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction /… Andreas Gruenbacher
- Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction /… J. Bruce Fields
- Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction /… Andreas Gruenbacher
- Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction /… Sam Falkner
- Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction /… Sam Falkner
- Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction /… Lisa Week
- Re: [NFS] [nfsv4] Re: NFSv4 ACL and POSIX interac… Andreas Gruenbacher
- Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction /… Andreas Gruenbacher
- Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction /… Andreas Gruenbacher
- Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction /… Andreas Gruenbacher
- Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction /… Sam Falkner
- Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction /… Sam Falkner
- Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction /… J. Bruce Fields
- [nfsv4] Re: [NFS] NFSv4 ACL and POSIX interaction… J. Bruce Fields
- Re: [nfsv4] Re: [NFS] NFSv4 ACL and POSIX interac… J. Bruce Fields
- Re: [nfsv4] Re: [NFS] NFSv4 ACL and POSIX interac… J. Bruce Fields
- RE: [nfsv4] Re: [NFS] NFSv4 ACL and POSIX interac… wurzl_mario
- Re: [nfsv4] Re: [NFS] NFSv4 ACL and POSIX interac… Andreas Gruenbacher
- Re: [nfsv4] Re: [NFS] NFSv4 ACL and POSIX interac… Andreas Gruenbacher
- Re: [nfsv4] Re: [NFS] NFSv4 ACL and POSIX interac… J. Bruce Fields
- Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction /… Sam Falkner
- Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction /… Andreas Gruenbacher
- Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction /… Andreas Gruenbacher
- Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction /… Lisa Week
- Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction /… Andreas Gruenbacher