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 09:00 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0E6J-00037h-0H; Tue, 11 Jul 2006 05:00:15 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0E6H-00037c-Ok for nfsv4@ietf.org; Tue, 11 Jul 2006 05:00:13 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0E6H-0006GX-NG for nfsv4@ietf.org; Tue, 11 Jul 2006 05:00:13 -0400
Received: from ns.suse.de ([195.135.220.2] helo=mx1.suse.de) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G0E4p-00007g-6a for nfsv4@ietf.org; Tue, 11 Jul 2006 04:58:45 -0400
Received: from Relay2.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 30A43EFE8; Tue, 11 Jul 2006 10:58:39 +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 10:55:55 +0200
User-Agent: KMail/1.9.1
References: <200607032310.15252.agruen@suse.de> <200607091822.44656.agruen@suse.de> <A15E619E-E88C-420C-AEC4-4E7409F187F3@Sun.COM>
In-Reply-To: <A15E619E-E88C-420C-AEC4-4E7409F187F3@Sun.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200607111055.56001.agruen@suse.de>
X-Spam-Score: -2.6 (--)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Cc: Sam Falkner <Sam.Falkner@sun.com>, nfs@lists.sourceforge.net, Spencer Shepler <spencer.shepler@sun.com>, Brian Pawlowski <beepy@netapp.com>, Lisa Week <Lisa.Week@sun.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 Tuesday, 11. July 2006 08:50, Lisa Week wrote:
> On Jul 9, 2006, at 10:22 AM, Andreas Gruenbacher wrote:
> > Note that in traditional POSIX, permissions from multiple file
> > classes will never accumulate: each user always is either granted the
> > File Owner permission bits, the File Group permission bits, or the File
> > Other permission bits. (Additional file access control mechanisms may
> > further limit the permissions granted, and alternative file access
> > control mechanisms may further limit or extend the permissions granted.)
> > Permissions from multiple acl entries accumulate in the NFSv4 ACL model
> > though, and so unless an acl is "well structured" in the above sense,
> > permissions from multiple classes may accumulate.
>
> Yes, permissions may accumulate, but in the design in the minor
> version doc, after a chmod, any permissions that go beyond the mode
> bits being set will be disabled.  This is done via the algorithm in
> section 3.16.6.3 -  "Applying a Mode to an Existing ACL".  This makes
> sure that the permissions (ACE4_READ_DATA/ACE4_LIST_DIRECTORY,
> ACE4_WRITE_DATA/ACE4_WRITE_DATA, ACE4_APPEND_DATA/
> ACE4_ADD_SUBDIRECTORY and ACE4_EXECUTE... which is what the mode
> defines) that accumulate will NOT go beyond the mode bits being set.

Ack.

Andreas

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4