Enable auto-elevation for a profile, redux

[zadjii-msft]

targets #11308

Summary of the Pull Request

This is the resurrection of #8514.

This PR adds two features:

• the elevate: bool property to profiles
  • If the user is running unelevated, and elevate is set to true, then instead of opening a new tab, we'll open an elevated Terminal window with the profile.
  • Otherwise, we'll just open a new tab in the existing window. This includes cases where the window is elevated, and the profile is set to elevate:false. elevate:false basically just means "do nothing special with me".
• the elevate: bool? property to NewTerminalArgs (newTab, splitPane)
  • This allows a user to create an action that will elevate the profile, even if the profile is not otherwise set to auto-elevate.
  • elevate:null (the default) does not change the profile's elevation status. The action will use whatever is set by the profile.
  • elevate:true will attempt to auto-elevate the profile
  • elevate:false will do nothing special.

References

• Scenario: Windows Terminal 2.0 Process Model Improvements #5000 for obvious reasons
• Spec'd in Spec for Elevation QOL improvements #8455
• requires Prompt before launching commandlines when elevated ; cache answers in elevated state.json #11096 as the vegetables to this PR's candy, for security's sake.

PR Checklist

• Closes [Question] Configuring Windows Terminal profile to always launch elevated #632
• I work here
• Tests added/passed
• Requires documentation to be updated - sure does, but that'll come all at the end.

Detailed Description of the Pull Request / Additional comments

After playing with de-elevation a bit, it turns out it behaves weirdly with packaged applications. I can try and ask explorer.exe to launch the process on our behalf. However, if the thing we're launching is an execution alias (wt.exe), and we're elevated, then the child process will still launch elevated.

There's also something super BODGEY at work here. ShellExecute is the function we use to ask the OS to elevate something for us. But ShellExecute needs to be able to send a window message to the process that called it (if the caller was a WINDOWS subsystem application). So if we die immediately after calling ShellExecute, then the elevated process never actually spawns - sad. So we're adding a helper process, elevate-shim.exe, that lives in our process. That'll be the one that actually calls ShellExecute, so that it can live for the duration of the UAC prompt.

Validation Steps Performed

• Ran tests
• Opened a bunch of terminal tabs at various different elevation levels
• opened new splits too
• In the defaults (base layer) as well, for madness

Some settings to use for testing

    "keybindings" :
    [
        ////////// ELEVATION ///////////////
        { "keys": "f1", "name": "ELEVATED TAB", "icon": "\uEA18", "command": { "action": "newTab", "elevate": true } },
        { "keys": "f2", "name": "ELEVATED, Color", "icon": "\uEA18", "command": {
            "action": "newTab", "elevate": true, "commandline": "PowerShell.exe", "startingDirectory": "C:\\Windows", "tabColor": "#bbaa00"
        } },
        { "keys": "f3", "name": "unelevated ELEVATED", "icon": "🙃", "command": {
            "action": "newTab", "elevate": false, "profile": "elevated cmd"
        } },
        //////////////////////////////
    ],

    "profiles":
    {
        "defaults":
        {
            "elevate": true,
        },
        "list":
        [
            {
                "hidden":false,
                "name" : "cmd",
                "commandline" : "cmd.exe",
                "guid": "{0caa0dad-35be-5f56-a8ff-afceeeaa6101}",
                "startingDirectory" : "%USERPROFILE%",
                "opacity" : 20
            },
            {
                "name" : "the COOLER cmd",
                "commandline" : "c:\\windows\\system32\\cmd.exe",
                "startingDirectory" : "%USERPROFILE%",
            },
            {
                "name" : "the sneaky cmd",
                "commandline" : "c:\\windows\\system32\\cmd.exe /k echo sneaky sneaks",
                "startingDirectory" : "%USERPROFILE%",
            },
            {
                "name": "elevated cmd",
                "commandline": "cmd.exe /k echo This profile is always elevated",
                "startingDirectory" : "well this is garbage",

                "elevate": true,
                "background": "#9C1C0C",
                "tabColor": "#9C1C0C",
                "colorScheme": "Desert"
            },
            {
                "name": "unelevated cmd",
                "commandline": "cmd.exe /k echo This profile is just as elevated as you started with",
                "elevate": false,
                "background": "#1C0C9C",
                "tabColor": "#1C0C9C",
                "colorScheme": "DotGov",
                "useAcrylic": true
            },
        ]

Also try:

• wtd nt -p "elevated cmd" ; sp -p "elevated cmd"
• wtd nt -p "elevated cmd" ; nt -p "elevated cmd"

[miniksa]

After playing with de-elevation a bit, it turns out it behaves weirdly with packaged applications. I can try and ask explorer.exe to launch the process on our behalf. However, if the thing we're launching is an execution alias (wt.exe), and we're elevated, then the child process will still launch elevated.

That is odd, but seems like only a subset of the world, not the majority issue. So perhaps we log a follow up for that?

[zadjii-msft]

That is odd, but seems like only a subset of the world, not the majority issue. So perhaps we log a follow up for that?

I think there's already a deliverable on the msix team for this one 😉

[carlos-zamora]

I don't really have anything to add other than "update Hash() too". I would like some resolution/follow-up on (1) the sleep issue and (2) the window not being created sometimes issue.

[carlos-zamora]

These are all little things and I'm sure @miniksa (or somebody else) will come back to review this. Thanks!

[carlos-zamora]

Double check if we want to remove any of these. I'm not sure what configs we want for elevate-shim

[miniksa]

Something in my head thought that elevated-shim.exe could maybe be an Out-of-proc call server for the Terminal... but then I went meh.

If we already had terminalsvc.exe or whatever (like we want in order to capture the launch hotkey when the Terminal isn't already running), the elevate shim call could be OOP'd to there as it would stay alive for a long time.

But whatever. This works and makes sense.

[miniksa]

Have we filed this in papercuts?

[miniksa]

(or written BODGY here... cuz that's a representation of cut workarounds...)

[zadjii-msft]

thought that elevated-shim.exe could maybe be an Out-of-proc call server for the Terminal

that's a fun idea but something about the idea of elevated, packaged COM made me think that certainly won't work. I wonder why I'd have that preconception in my head 😝

[miniksa]

thought that elevated-shim.exe could maybe be an Out-of-proc call server for the Terminal

that's a fun idea but something about the idea of elevated, packaged COM made me think that certainly won't work. I wonder why I'd have that preconception in my head 😝

We'll just make a custom transport on a loopback socket... or we could just do this.

[zadjii-msft]

As discussed, we're gonna rebase this onto main, without #11308.