Thread (2 messages) 2 messages, 2 authors, 2015-09-28

Re: [PATCH v8 00/41] Richacls

From: J. Bruce Fields <hidden>
Date: 2015-09-28 17:46:48
Also in: linux-api, linux-fsdevel, linux-nfs, lkml

Possibly related (same subject, not in this thread)

On Mon, Sep 28, 2015 at 07:10:06PM +0200, Andreas Grünbacher wrote:
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?
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?

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.

--b.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help