Server-side NFSv4 ACL support

[J. Bruce Fields]

On Tue, Aug 08, 2006 at 09:45:54PM -0500, Prasad P wrote:
>     All versions of NFS (server and client) support POSIX ACLs.  But, only
>     NFSv4 client supports NFSv4 ACLs.

Well, actually the way that the NFS server supports "POSIX ACLs" is by
mapping between them and NFSv4 ACLs.

That mapping is currently extremely picky--it won't accept an NFSv4 ACL
that isn't precisely in the form described by

http://www.citi.umich.edu/projects/nfsv4/rfc/draft-ietf-nfsv4-acl-mapping-03.txt

>     1. Implement NFSv4 ACLs by storing the ACLs on the file system (as an
>        extended attribute, or in a special file).
>         Pros: Can support NFSv4 ACLs while keeping all the code changes in
>               the NFS code and not needing to coordinate with the 
> underlying
>               file systems.  This approach helps when a Linux system is
>               configured as NFS server without local access (similar to 
> NAS
>               appliance).
>         Cons: The NFSv4 ACLs can not be used by the local users.

Also:

	- The access checks are more likely to be buggy, since now you have
	  to do all the file access checks in nfsd instead of relying on
	  common filesystem code
	- Problems will arise from inconsistent enforcement of
	  permissions across NFS users, local users, and users accessing
	  the filesystem via other protocols.

>     2. Standardize the ACL interface with the underlying file system, and
>        support NFSv4 ACLs only when the underlying file system supports 
> NFSv4
>        style ACLs.

This is what Solaris is doing with ZFS; I believe they're also 
discontinuing support for the sideband NFSACL protocol on ZFS.

Andreas Gruebacher has been working on this on Linux; see

	http://www.suse.de/~agruen/nfs4acl/

for his work in progress.

I assume this would also be very useful to Samba.

>         Pros: Development work is involved in NFS area only for the NFS
>               developers.  Can support NFSv4 ACLs on the file systems 
>		which currently support NFSv4 style ACLs.
>         Cons: Need to involve file systems developers to implement NFSv4 
> ACLs.

Well, the real difficulty here is that we're going to support NFSv4 ACLs
on filesystems that users also expect to run posix applications on,
install their system binaries and software on, etc., then we *must* get
the interactions with mode bits correct.  This is a solvable problem,
but a non-trivial one.

>     4. Map POSIX ACLs to NFSv4 ACLs
>         Pros: Minimal development time to verify the existing 
>		implementation and improve/correct where ever possible to
>		reduce the imperfectness.
>         Cons: Can not use full range of NFSv4 ACLs.  Weak access controls.

There are some improvements we could make to the NFSv4<->POSIX ACL
mapping to allow us to accept the full range of NFSv4 ACLs (except
audit/deny aces) and still provide some minimal guarantees on the access
controls (for example, that when setting an ACL, the ACL actually set
will be no more permissive than the one given); see

http://www.citi.umich.edu/projects/nfsv4/rfc/draft-ietf-nfsv4-acl-mapping-04.txt

But of course this is a complex and incomplete solution.

> IV. References:
>     1. RFC3530 (Network File System (NFS) version 4 Protocol)
>     2. POSIX 1003.1e draft
>     3. ACLs wiki page (http://wiki.linux-nfs.org/index.php/ACLs)

See also the archives of the nfsv4 ietf working group list.

Is this something you're interested in contributing to?

--b.