Re: [nfsv4] I-D ACTION:draft-ietf-nfsv4-acl-mapping-05.txt

"J. Bruce Fields" <bfields@fieldses.org> Wed, 30 August 2006 18:05 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIUR9-0003O1-2n; Wed, 30 Aug 2006 14:05:15 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIUR7-0003MJ-Sp for nfsv4@ietf.org; Wed, 30 Aug 2006 14:05: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 1GIT00-0007TN-GY for nfsv4@ietf.org; Wed, 30 Aug 2006 12:33:08 -0400
Received: from mail.fieldses.org ([66.93.2.214] helo=pickle.fieldses.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GISxd-0003ku-Tg for nfsv4@ietf.org; Wed, 30 Aug 2006 12:30:42 -0400
Received: from bfields by pickle.fieldses.org with local (Exim 4.63) (envelope-from <bfields@fieldses.org>) id 1GISxd-0006ed-5O for nfsv4@ietf.org; Wed, 30 Aug 2006 12:30:41 -0400
Date: Wed, 30 Aug 2006 12:30:41 -0400
To: nfsv4@ietf.org
Subject: Re: [nfsv4] I-D ACTION:draft-ietf-nfsv4-acl-mapping-05.txt
Message-ID: <20060830163041.GA17262@fieldses.org>
References: <E1GFyji-00067f-5N@stiedprstage1.ietf.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <E1GFyji-00067f-5N@stiedprstage1.ietf.org>
User-Agent: Mutt/1.5.13 (2006-08-11)
From: "J. Bruce Fields" <bfields@fieldses.org>
X-Spam-Score: -2.6 (--)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
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 Wed, Aug 23, 2006 at 03:50:02PM -0400, Internet-Drafts@ietf.org wrote:
> 	Title		: Mapping Between NFSv4 and Posix Draft ACLs
> 	Author(s)	: M. Eriksen, J. Fields
> 	Filename	: draft-ietf-nfsv4-acl-mapping-05.txt
> 	Pages		: 20
> 	Date		: 2006-8-23

So the problem here has been that a server implementing this mapping is
so picky that a user *must* use a posix acl utility to set acls.  That
means we have to provide both posix and nfsv4 acl utilities and train
them to use one or the other depending on which server they're talking
to (or which filesystem them server is exporting).

In practice, since the posix acl utility will work (more or less) on
both, that means they'll probably just use it.  But this saddles all the
servers with weird requirements of the similarly picky client-side
mapping.

We're all working on implementing NFSv4 ACLs natively on our server
filesystems, which will solve the problem for new filesystems.

This draft solves the problem as completely as possible without
requiring a filesystem upgrade, by making a server exporting a posix-acl
filesystem support a much wider range of NFSv4 ACLs.

Changes to this draft:

	- sketches argument that the mapping actually takes any NFSv4
	  ACL to the unique POSIX ACL that is "closest" to the given NFSv4
	  ACL without being more permissive[1];
	- includes new description of the NFSv4->posix ACL mapping that
	  should be easier to implement from;
	- includes discussion of compatibility with old mapping, with a
	  brief description of the old mapping.

I've implemented the new NFSv4->posix mapping in the Linux server, and
could post some cleaned-up sample code at some point.

So the point of all this is that there's no longer any excuse for a
server (even one with backend posix acls) not to accept close to the
full range of NFSv4 ACLs.

--b.

[1]  Gory details: by the "closest" ACL we mean the most permissive ACL
that isn't more permissive than the given ACL.  The POSIX ACL is unique
only up to some choices of mask and inheritance flags.  Some ACLs (such
as acls with explicit denies of read_attributes, or that use unsupported
inheritance flags) may still have to be rejected.

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