Return empty string instead of throwing when getpwuid_r fails unexpectedly

[HarnageaGabriel]

Fixes#119216

Problem

GetUserNameFromPasswd's XML doc already documents that it returns an empty string on failure. That contract already holds when /etc/passwd is readable but the current UID isn't present (getpwuid_r returns -1/ENOENT-equivalent → TryGetUserNameFromPasswd returns null).

But when getpwuid_r fails for any other reason — notably when /etc/passwd itself doesn't exist, as can happen in restricted sandboxes/containers — TryGetUserNameFromPasswd threw an IOException instead. That exception propagates up through Environment.UserName and crashes the calling process (e.g. dotnet build, dotnet new) instead of degrading gracefully.

Repro (from the issue)

docker run -it ubuntu:24.04
apt update && apt install -y dotnet-sdk-8.0
rm /etc/passwd
cd /root
dotnet new create console

Fix

src/libraries/Common/src/Interop/Unix/System.Native/Interop.GetPwUid.cs: in TryGetUserNameFromPasswd, the fallback branch after the ERANGE (buffer-too-small) check no longer throws — it now sets username = null and returns true, same as the "current user not found" path, so GetUserNameFromPasswd returns string.Empty instead of propagating the exception. The ERANGE retry-with-larger-buffer behavior is unchanged.

Also removed the now-unused using System.IO;.

Testing

This is a small interop fix in src/libraries/Common (shared source, no dedicated isolated test project); given the size of the dotnet/runtime repo I did not run a full runtime build. I verified the change by inspecting the diff and confirming no other caller relies on the previously-thrown IOException (checked Environment.UserName in Environment.Unix.cs, the only caller).

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[HarnageaGabriel]

@dotnet-policy-service agree

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-runtime
See info in area-owners.md if you want to be subscribed.

[jeffhandley]

Thanks, @HarnageaGabriel!

[AaronRobinsonMSFT]

This seems like a user visible behavioral change that should have a test. Clearly this was a test hole when it was written and now that we're addressing it here we might consider taking the opportunity to add some verification?

/cc @jeffhandley

[HarnageaGabriel]

Good call — added coverage in ee86dae.

I extracted the error-code decision out of TryGetUserNameFromPasswd into a small internal helper, ShouldRetryGetUserNameFromPasswd(int error), which only decides "retry with a larger buffer" (true, ERANGE) vs. "no user name" (false, everything else including -1/not-found and unexpected errors). The native getpwuid_r call and all other logic are unchanged.

Since a real "unexpected getpwuid_r failure" (e.g. EIO) isn't something you can reliably force through the actual syscall in a portable xunit test, and there's no existing DI seam for this P/Invoke shim, I unit-tested the extracted helper directly instead — same pattern already used by Win32Marshal.Tests in this test project for similar error-code-to-outcome logic. New tests in GetPwUidTests.cs cover:

• -1 (user not found) → no retry
• ERANGE → retry
• EIO (stand-in for an unexpected error) → no retry, which is what now surfaces as Environment.UserName returning "" instead of throwing.

I wasn't able to run the full test suite locally (this repo's local build requires enabling Windows long paths system-wide, which I didn't want to do unilaterally in this environment), but the change is a pure extraction with no behavioral difference, and I reviewed the resulting logic carefully against the original branching.