virtiofs: fix an issue where if the VM is launched by an elevated user, non-elevated shells will have elevated virtiofs access.

[benhillis]

Resolves an issue with virtiofs when WSLg is enabled. If an elevated token launches the VM, then all virtiofs access will have access rights of the launching token. A test was added to validate the fix, the previous tests did not hit this because they run with WSLg disabled.

[Copilot]

Pull request overview

This PR fixes a security issue where VirtioFS mounts incorrectly inherit elevated access rights when the VM is launched by an elevated user, even when accessed from non-elevated shells. The fix ensures that the appropriate VirtioFS class ID is selected based on the token's elevation status when WSLg (GUI applications) is enabled.

Key changes:

• Modified virtiofs device initialization to use elevation-aware class ID selection
• Added comprehensive tests to validate elevated and non-elevated access with WSLg enabled

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
src/windows/service/exe/WslCoreVm.cpp	Implements the fix by checking token elevation and selecting the appropriate VIRTIO_FS class ID (admin vs non-admin) when adding the wslg shared memory device
test/windows/DrvFsTests.cpp	Adds two new test methods (DrvfsMountElevatedSystemDistroEnabled and DrvfsMountNonElevatedSystemDistroEnabled) that validate the fix by testing mount types and file creation permissions with WSLg enabled