-
Notifications
You must be signed in to change notification settings - Fork 8.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Run as Admin shortcut + elevate:true -> crash loop #13928
Comments
I read them before I raised the issue.I logged in as my admin user,the only user on my windows,and tried to install Terminal from the MicrosoftStore,yet it still didn't work. |
Oh man, you know what, I think another thread might have a better repro. Copying deets here.
|
Repro'd a version of the crash loop with the default edit: these instructions reproduce the bug; I'm not aware of a fix.
Change the default profile settings "profiles":
{
"defaults": { "elevate": true },
... Root CauseI built a custom dev build with some extra logging in the utils.cpp IsElevated check. The built-in Administrator account meets the criteria that it has a This interacts with In short, the check for https://github.com/microsoft/terminal/blob/main/src/types/utils.cpp#L664-L673 if (elevationType == TokenElevationTypeDefault && elevationState.TokenIsElevated)
{
// In this case, the user has UAC entirely disabled. This is sort of
// weird, we treat this like the user isn't an admin at all. There's no
// separation of powers, so the things we normally want to gate on
// "having special powers" doesn't apply.
//
// See GH#7754, GH#11096
return false;
} Related Docs: TokenElevationTypeDefault: Type 1 is a full token with no privileges removed or groups disabled. A full token is only used if User Account Control is disabled or if the user is the built-in Administrator account (for which UAC disabled by default), service account or local system account. |
procmon trace (screenshot) of the loop on latest 1.16.10261.0. This is running under the default Administrator account on 10.0.22621.1105 with elevate=true in the defaults. The sequence doesn't look right given some lost events, but the PID parent/child relationships are as expected. WindowsTerminal.exe doesn't think it's elevated (per comment above); it's launching elevate-shim which is using shell:Appsfolder with the runas verb to launch WindowsTerminal elevated and the cycle repeats. |
Ah, heck. This came up in an earlier code review that we didn't end up merging, too. We need separate checks for |
…/drop Credit where credit is due - @jboelter did literally all the hard work. I just separated this out to two elements: * Are we running elevated? * Can we drag drop? As we learned in #7754, the builtin administrator _can_ drag drop. But critically, they are also running as admin! The way we had this logic before, we're treat them as unelevated, because we had been overloading the meaning here. This splits these into two separate functions. Comes with the added benefit of re-adding the elevation shield to the Terminal window for users with UAC disabled (which was missing before) (and can _still_ be disabled). Closes #13928 Tested on a Win10 VM with `EnableLua=0`
Credit where credit is due - @jboelter did literally all the hard work. I just separated this out to two elements: * Are we running elevated? * Can we drag drop? As we learned in #7754, the builtin administrator _can_ drag drop. But critically, they are also running as admin! The way we had this logic before, we're treat them as unelevated, because we had been overloading the meaning here. This splits these into two separate functions. Comes with the added benefit of re-adding the elevation shield to the Terminal window for users with UAC disabled (which was missing before) (and can _still_ be disabled). Closes #13928 Tested on a Win10 VM with `EnableLua=0`
Credit where credit is due - @jboelter did literally all the hard work. I just separated this out to two elements: * Are we running elevated? * Can we drag drop? As we learned in #7754, the builtin administrator _can_ drag drop. But critically, they are also running as admin! The way we had this logic before, we're treat them as unelevated, because we had been overloading the meaning here. This splits these into two separate functions. Comes with the added benefit of re-adding the elevation shield to the Terminal window for users with UAC disabled (which was missing before) (and can _still_ be disabled). Closes #13928 Tested on a Win10 VM with `EnableLua=0` (cherry picked from commit c5c15e8) Service-Card-Id: 88484047 Service-Version: 1.17
Windows Terminal version
1.14.2281.0 or preview 1.15.2282.0
Windows build number
10.0.19044.0
Other Software
No response
Steps to reproduce
Expected Behavior
No response
Actual Behavior
bandicam.2022-09-06.11-26-11-658.mp4
I also tried run terminal as administrator,but it seemed didn't work.
The text was updated successfully, but these errors were encountered: