[Bug 296753] nfsuserd caches successful name-to-ID mappings under canonical NSS names instead of the requested NFSv4 name

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=296753

            Bug ID: 296753
           Summary: nfsuserd caches successful name-to-ID mappings under
                    canonical NSS names instead of the requested NFSv4
                    name
           Product: Base System
           Version: 15.1-RELEASE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: bin
          Assignee: bugs@FreeBSD.org
          Reporter: emanuel@nrv.cc

Created attachment 272798
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=272798&action=edit
Patch.

When an NSS backend returns a canonical pw_name or gr_name that differs from
the lookup name supplied by the NFSv4 upcall, nfsuserd stores the successful
mapping in the kernel cache under the canonical name instead of the requested
name.

This causes the retry lookup performed by nfsv4_strtouid() or
nfsv4_strtogid() to miss the newly inserted cache entry, resulting in the
default UID/GID being returned although the NSS lookup itself succeeded.

I reproduced this with:

- FreeBSD 15.1-RELEASE
- NFSv4.1 client (sec=krb5i)
- Winbind as NSS backend
- Samba Active Directory with RFC2307 uidNumber/gidNumber
- Synology DSM 7.4 NFS server

The server returns owner names such as:

    EXAMPLE\alice@example.org
    EXAMPLE\Domain Users@example.org

After the configured NFSv4 domain suffix is removed, the kernel requests
lookups for:

    EXAMPLE\alice
    EXAMPLE\Domain Users

Winbind resolves these correctly to the RFC2307 IDs, but with
"winbind use default domain = yes" returns canonical names such as "alice"
and "Domain Users". nfsuserd currently inserts those canonical names into the
kernel cache.

As a result:

- getent passwd 'EXAMPLE\alice' succeeds
- getent group 'EXAMPLE\Domain Users' succeeds
- Kerberos authentication succeeds
- access permissions work correctly
- stat(2) and ls(1) display nobody:nogroup (65534/65533)

The attached patch changes only the successful name-to-ID paths so that the
cache key remains the exact name that triggered the upcall while the UID/GID
continues to come from NSS.

ID-to-name lookups, failed lookups, timeout handling, group-list handling,
Kerberos processing and domain validation are unchanged.

The patch builds cleanly on FreeBSD 15.1 and fixes the issue in my test
environment.


Steps to Reproduce

1. Configure a FreeBSD 15.1 client to use Winbind as the NSS backend.
2. Join an Active Directory domain with RFC2307 uidNumber/gidNumber attributes.
3. Configure "winbind use default domain = yes".
4. Mount an NFSv4.1 export using sec=krb5i.
5. Use a server that returns owner names in the form:
       DOMAIN\user@example.org
6. Access files on the export.


Actual Results

Successful NSS lookups are cached under the canonical pw_name/gr_name rather
than the requested NFSv4 name, causing subsequent kernel cache lookups to
miss. File ownership is displayed as nobody:nogroup.


Expected Results

Successful name-to-ID mappings should be cached under the exact name supplied
by the NFSv4 upcall so that subsequent kernel lookups resolve correctly.

-- 
You are receiving this mail because:
You are the assignee for the bug.