On Thu, May 28, 2015 at 7:06 PM, Trond Myklebust <trond.myklebust@xxxxxxxxxxxxxxx> wrote: > On Fri, Apr 24, 2015 at 7:04 AM, Andreas Gruenbacher > <andreas.gruenbacher@xxxxxxxxx> wrote: >> Changes nfs to support the "system.richacl" xattr instead of "system.nfs4_acl". >> > > NACK. > > You may declare a userspace syscall ABI that is more than 10 years old > to be deprecated, but you are not allowed to remove it. > So having revisited the reasons why I chose the system.nfs4_acl interface when we did NFSv4 ACLs, I'm not sure we should implement system.richacl for the NFS client at all. The problem is that you are 100% reliant on an accurate idmapper in order to convert the name@domain to a _correct_ uid/gid. It isn't sufficient to convert to just any valid uid/gid, because if your ACL tool is trying to edit the ACL, you can end up converting all those DENY modes for user 'Johnny_Rotten@xxxxxxxxxxxxxxxx' into DENY modes for user 'nobody'. ...and yes, libnfsidmap will happily convert all unknown user/groupnames into whatever uid/gid corresponds to 'nobody' without returning an error. Your assertion that "when symbolic user@domain and group@domain names are used in the acl, user-space needs to perform ID mapping in the same way as the kernel" is WRONG. User space needs do no such thing, and that was the whole point of the interface; to allow the user to specify ACLs in a format that is checked only on the _server_, and not on the client. Trond -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
