Re: nfs4-acl-tools 0.3.5

["J. Bruce Fields" <bfields@fieldses.org>]

On Thu, Aug 23, 2018 at 05:50:22PM -0700, Paul B. Henson wrote:
> Hmm, the door is open a crack :). When I get a chance to put
> something together I'll be back…

OK.  I can't promise anything.  It all depends on whether it would make
any sense for the NFS reexport case, and I just don't know.

> 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.

It'd be simplest to pass it straight through, but the complicated issue
is names.  See the logic in fs/nfsd/idmap.c which defaults to string
names in the krb5 case (where we assume the necessary infrastructure to
get that right is all set up), but ascii-encoded numeric id's in the
auth_sys case (when legacy numeric ID's are the simpler default).

--b.