Re: [PATCH] nfsuserd: Preserve requested names in name-to-ID cache entries

On Fri, Jul 10, 2026 at 11:16=E2=80=AFAM Emanuel HelmsEmanuel Helms
<[email protected]> wrote:
>
> CAUTION: This email originated from outside of the University of Guelph. =
Do not click links or open attachments unless you recognize the sender and =
know the content is safe. If you are unsure, forward the message to ITHelp@=
uoguelph.ca for review.
>
>
> Hello Rick,
>
> I found an NFSv4 name-to-ID caching issue in nfsuserd on FreeBSD 15.1 and
> would appreciate your review of the attached patch.
>
> The setup in which I reproduced the issue consists of:
>
> - a FreeBSD 15.1 NFSv4 client;
> - Winbind as the passwd/group NSS backend;
> - an Active Directory domain provided by Samba on Rocky Linux 9;
> - RFC2307 uidNumber and gidNumber attributes in AD;
> - a Synology DSM 7.4 NFS server; and
> - a Kerberos-protected NFSv4.1 mount using sec=3Dkrb5i.
>
> An equivalent fstab entry is:
>
> nfs.example.org:/volume2/share  /mnt/share  nfs
> rw,nfsv4,minorversion=3D1,sec=3Dkrb5i  0  0
>
> The corresponding manual mount command is:
>
> mount -t nfs -o nfsv4,minorversion=3D1,sec=3Dkrb5i \
>      nfs.example.org:/volume2/share /mnt/share
>
> The DSM server returns owner and owner_group attributes in a
> domain-qualified form, for example:
>
> EXAMPLE\[email protected]
> EXAMPLE\Domain [email protected]
>
> The configured NFSv4 domain is example.org. FreeBSD correctly removes the
> matching @example.org suffix before making the nfsuserd upcall. The
> resulting
> lookup names are therefore "EXAMPLE\alice" and "EXAMPLE\Domain Users".
>
> Winbind successfully resolves these names to the RFC2307 IDs. However, wi=
th
> "winbind use default domain =3D yes", getpwnam("EXAMPLE\alice") returns a
> passwd structure whose pw_name is the canonical short name "alice". The s=
ame
> canonicalization occurs for group lookups.
>
> RPCNFSUSERD_GETUSER currently inserts the successful mapping into the ker=
nel
> cache using pwd->pw_name. The cache entry is therefore created for "alice=
",
> while nfsv4_strtouid() retries its lookup for the originally requested na=
me
> "EXAMPLE\alice". That cache lookup misses and the owner is ultimately map=
ped
> to the default UID. RPCNFSUSERD_GETGROUP has the same behavior with
> grp->gr_name.
>
> This produces the following symptoms:
>
> - getent passwd 'EXAMPLE\alice' returns the correct RFC2307 UID;
> - getent group 'EXAMPLE\Domain Users' returns the correct RFC2307 GID;
> - Kerberos authentication and access to the export work;
> - nfsuserd -verbose logs that it found and added the correct numeric ID, =
but
>    logs the canonical short name; and
> - stat(2) and ls(1) report 65534/65533 and nobody:nogroup for the NFS
> object.
>
> The attached patch changes only the two successful name-to-ID paths. The =
UID
> or GID still comes from the NSS result, but nid_name remains the exact na=
me
> that caused the upcall. This lets the retry in nfsv4_strtouid() or
> nfsv4_strtogid() find the newly inserted entry.
>
> The ID-to-name paths, failed lookup behavior, timeout handling, group-lis=
t
> handling, Kerberos processing, and domain validation are unchanged. In th=
e
> usual case where the requested and canonical NSS names are identical, the
> resulting cache key is also identical to the current one.
>
> After applying the patch and rebuilding nfsuserd, newly fetched attribute=
s
> map to the expected RFC2307 UID and GID on the first lookup and on
> subsequent
> cached lookups. Short Winbind login names continue to work. I also verifi=
ed
> that the source builds with the FreeBSD 15.1 build flags and warnings
> enabled.
>
> There is a possible broader benefit beyond Winbind: any NSS backend that
> successfully resolves an alias but returns a different canonical pw_name =
or
> gr_name can trigger the same mismatch. Caching the result under the name
> that
> was actually requested appears to match the semantics of NFSID_ADDUSERNAM=
E
> and NFSID_ADDGROUPNAME.
>
> Please let me know if you would prefer the change in a different form or
> want
> additional diagnostics or testing.
Please put this in bugs.freebsd.org. You can put the patch in an attachment=
.
That way it won't get forgotten, at least hopefully.

Thanks, rick

>
> Best regards,
>
> Emanuel Helms