Re: nfs4-acl-tools 0.3.5

["Paul B. Henson" <henson@acm.org>]

On 8/23/2018 1:57 PM, J. Bruce Fields wrote:

> Honestly the system.nfs4_acl extended attribute interface, which
> just exposes the raw xdr of the ACL to userspace, is kind of a
> kludge.  It could be made to work for other filesystems but I was
> hoping that other filesystems would adopt something designed for them
> from scratch (like richacls).

I agree; but it's what I have to work with :). And from a pragmatic 
perspective I'd rather have something that works even if not perfect 
than perfect vaporware I can't use ;). If something like richacls comes 
along at some point in the future it should be possible to migrate to it.

> That said, there *is* already an in-kernel filesystem that supports 
> system.nfs4_acl: knfsd does actually allow limited re-export of NFS.
> So knfsd code that used system.nfs4_acl when available might actually
> have some use, I don't really know.  I'm a little skeptical of the
> idea, to be honest.

Hmm, the door is open a crack :). When I get a chance to put something 
together I'll be back…

 From a design perspective, would you want this to just take the 
verbatim xdr encoded acl from the file system and shove it over the 
wire, or would you want the NFS server to decode the acl received from 
the extended attribute, process or sanity check as necessary, and then 
re-encode it to send over the wire? The same I guess for ones received 
over the network, pass as is to fs xattr call or decode/re-encode.

Thanks…