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…
