Re: [RFC v3 42/45] nfs: Add richacl support

[Trond Myklebust]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/