On Tue, Sep 29, 2015 at 4:54 PM, Andreas Grünbacher
[off-list ref] wrote:

2015-09-28 19:46 GMT+02:00 J. Bruce Fields [off-list ref]:

quoted

On Mon, Sep 28, 2015 at 07:10:06PM +0200, Andreas Grünbacher wrote:

quoted

2015-09-28 18:35 GMT+02:00 J. Bruce Fields [off-list ref]:

quoted

On Mon, Sep 28, 2015 at 12:08:51AM +0200, Andreas Gruenbacher wrote:

quoted

Open issues in nfs:

* When a user or group name cannot be mapped, nfs's idmapper always maps it
  to nobody. That's good enough for mapping the file owner and owning
  group, but not for identifiers in acls. For now, to get the nfs richacl
  support somewhat working, I'm explicitly checking if mapping has resulted
  in uid/gid 99 in the kernel.

* When the nfs server replies with NFS4ERR_BADNAME for any user or group
  name lookup, the client will stop sending numeric uids and gids to the
  server even when the lookup wasn't numeric.  From then on, the client
  will translate uids and gids that have no mapping to the string "nobody",
  and the server will reject them.  This problem is not specific to acls.

Do you have fixes in mind for these two issues?

I'm not sure how to best fix the idmapper problem, with backwards
compatibility and all.

I haven't looked at the current nfsidmap interface....  So it's
completely lacking any way to communicate failure?

Yes, when a user doesn't exist, idmapper maps that to the nobody
uid/gid. That's the failure mode of stat. In the acl case, we do want
to map user and group names to their respective ids where possible (so
that the acl makes sense in the local system context), but we do want
to preserve the original user and group names when there is no such
mapping instead of mapping to the nobody uid/gid.

So that's fixed now in nfs-utils and the latest richacl snapshot.

quoted

quoted

The second problem shouldn't be too hard to fix.

Is it enough to turn off the failover in the case there's no possibility
it could have been caused by a numeric id?

Yes, I believe that would be enough.

quoted

If any user can set ACLs with arbitrary strings as names, then we'd be
giving any user unprivileged user the ability to turn off numeric
idmapping, so I think we need to fix that.

The bug can be triggered by unprivileged users with nfs4_setfacl.

It turns out that when setting an ACL, the ACL can contain UID/GID
numbers as well as user@domain strings which the server cannot map.
The status code is NFS4ERR_BADNAME both when the server doesn't
support UID/GID numbers and when it cannot map a name, so in that
case, we cannot tell the difference.

Luckily, when a UID/GID cannot be mapped to a name, nfs falls back to
sending the server a UID/GID number instead even when
NFS_CAP_UIDGID_NOMAP has been cleared. So unprivileged users can turn
on the idmapper, but at least that doesn't break unmapped UIDs/GIDs.
(I got that wrong in my initial analysis.)

Thanks,
Andreas