Controlling root access for users

**Is your feature request related to a problem? Please describe.**

I am working on deploying WSL2 in an enterprise setting. The [enterprise guide](https://learn.microsoft.com/en-us/windows/wsl/enterprise) is a good resource for how to do this. One major missing feature is the ability to limit a Window user from accessing arbitrary Linux users. As it stands the WSL2 instance can be hardened with sudo rules and tight access controls, but these can be circumvented by passing `--user `. Even if you disable the login shell for the root user, you can run arbitrary commands with `--user root --exec `.

***This is a major issue for accreditation programs like CMMC which require tight privilege escalation management.***

The bottom of the [enterprise guide](https://learn.microsoft.com/en-us/windows/wsl/enterprise), last updated 08/16/2024, says:
> **Currently unsupported**
> Below is a list of commonly asked features that are currently unsupported within WSL. These requests are on our backlog and we are investigating ways to add them.
> ...
> - Controlling root access for users

Is this feature still in the backlog? Is there a projected timeline for when this feature might be available? Are there known workarounds or better solutions?

**Describe the solution you'd like**

The core requirement is that an admin can limit what WSL2 users can be accessed by a Windows user. There is a [WSL Intune document](https://learn.microsoft.com/en-us/windows/wsl/intune#control-wsl-commands) that describes settings such as `AllowDebugShell` and `AllowDiskMount` that restrict usage of those flags with the `wsl` application.

A solution could be in the form of:
- Limiting usage of `--user ` when calling `wsl` with the control `AllowNonDefaultUser`
- Limiting usage of `--exec ` when calling `wsl` with the control `AllowExec` or `AllowNonLoginShell`

**Describe alternatives you've considered**

- Blocking a user's access to running the wsl executable and allowing them access to run a trusted helper function that calls the wsl executable with an explicit user.
- I am not very familiar with Windows permissions and I'm not sure how feasible this is and whether this would mess up the permissions granted to the WSL2 distro (my understanding is it inherits the permissions of the calling user)
- Swapping to Hyper-V
- My teams are familiar with WSL2 and learning Hyper-V would be a setback, but I think Hyper-V has greater isolation and would not allow for the root backdoor that is `--user root --exec foo`

**Additional context**

I've run into a few instances of out of date or inconsistent documentation. That WSL Intune document refers to [Control access to WSL settings in .wslconfig](https://learn.microsoft.com/en-us/windows/wsl/intune#control-access-to-wsl-settings-in-wslconfig) which says:
> The last group of settings that end with `*UserSettingConfigurable` control access to WSL advanced settings in .wslconfig. When these are set to disabled then users will only be able to use the default value for that setting, and not able to configure it to custom values. Learn more about [Configuration setting for .wslconfig](https://learn.microsoft.com/en-us/windows/wsl/wsl-config#configuration-settings-for-wslconfig), including a list of settings that can be configured globally for all Linux distributions running with WSL 2.

That links to [all the settings for .wslconfig](https://learn.microsoft.com/en-us/windows/wsl/wsl-config#main-wsl-settings) and there are none with `*UserSettingConfigurable`.

Not sure what I'm missing here but the phasing `When these are set to disabled then users will only be able to use the default value for that setting, and not able to configure it to custom values` seems like it might be useful.

Start by reviewing the enterprise guide, WSL Intune control-access documentation, and the linked .wslconfig settings documentation to reconcile the documented controls with the requested restrictions. Define completion as an accepted design for limiting Windows-user access to Linux users and direct command execution, with corresponding documentation or implementation scope identified.

Written by the indexing model from the issue text.