Re: [RFC PATCH v2 40/41] nfsd, nfs: carry UUID and GUID owners as their text form

[Chuck Lever]

On 10/20/26 11:16 PM, Jan Koester wrote:
> Encode such an id as its text form -- "xxxxxxxx-xxxx-xxxx-xxxx-
> xxxxxxxxxxxx" for a UUID, the same in braces for a GUID -- in both
> directions on the server and the client, and take such a string (it
> has no '@', so it can't be a user@domain name) as that id again.

A bare UUID in an owner, owner_group, or ACE 'who' string is a new
owner-string syntax for NFSv4, one that only Linux would recognize.
Thus it isn't interoperable with other NFSv4 stacks as proposed
here.

RFC 8881 Section 5.9 says a string without an '@' that is not a
decimal number means no translation was available and the receiver
"should not use that string as a basis for translation into its
own internal format." RFC 8000 Section 6.1 forbids bare numeric
ids in multi-domain deployments because they collide; the same
applies to bare UUIDs, and more so to GUIDs.

If you are serious about pursuing this, you'll have to start by
raising the proposed wire format on nfsv4@xxxxxxxx before the
Linux kernel's NFS stack commits to it.

With nfs4_disable_idmapping and AUTH_SYS, numeric_name_to_id() and
encode_ascii_id() handle decimal ids in the kernel because there is
nothing to look up. Recognizing the text form in that branch only
would be the natural analogue once the format is agreed. Everything
else should go through the idmapper: extend the nametoid/idtoname
channels and the client keyring upcall to carry a 128-bit id, and
let rpc.idmapd and nfsidmap decide which strings map to which ids.
As written, the UUID check runs before idmapd for every name and
auth flavor, bypassing the cache and any site policy.

So my general preference for NFSv4 would be to pass the new format
up to the user space idmapper instead of handling these in-kernel
with no opportunity to apply local policy.


-- 
Chuck Lever (Come to NFS bake-a-thon! https://nfsv4bat.org)