Replies: 2 comments
-
Hi JensGJ.
I think you are misinterpreting the docs. There is no new policy enforced at all. There is a technical blocker to allow mixed elevation of tabs in a way that microsoft considers secure enough. MS pushed UAC and elevation as a security boundary, and are not confortable to build a bridge thru that isolation. As the doc says: having mixed tabs is "accepting risk for user convenience", so WT does not support it. But if you are willing to accept the risk, you can use gsudo to bridge between elevated-nonelevated, and therefore allow mixed elevation (on WT, on Win10 or 11).
Is this the same problem as #141 ? could you describe what the problem is? Do yo use Admin By Request on this system? If so, I would guess that it is the same bug with the "Admin by Request" tool. Are you running an updated ABR version? released after the bug was fixed? Maybe the ABR bug is back in the newer versions... Remember how to test without GSUDO? Please do this: #141 (comment) and let me know. |
Beta Was this translation helpful? Give feedback.
-
Hi Gerardo - thanks for a quick response.
Yes, it's the same problem - and Admin By Request is also running on the Windows 11 machine (company policy).
I have done the same test as earlier, eliminating gsudo from the equation, and the behavior is exactly as it was in the #141 bug report. I reported the bug under Windows 11 to FastTrack Software (the company behind Admin By Request) and to our own support office about a month ago - haven't heard back from any of them.
I'll try to poke them for an update now that I know that it is not Windows 11 that is blocking the functionality.
Best regards
Jens Gyldenkærne Jensen
Copenhagen Business School
|
Beta Was this translation helpful? Give feedback.
-
For some time I've been struggling to get gsudo to work with Windows Terminal on Windows 11. Earlier I had problems on Windows 10 due to a bug in the Admin By Request tool my company is using - that was solved and everything was fine for a while.
But after an upgrade to Windows 11 the problem has returned. And this time I'm not sure it can be fixed. I stumbled upon the following comment "Why can't we have mixed elevated and non-elevated tabs in the Terminal?" (https://github.com/microsoft/terminal/blob/main/doc/Niksa.md#elevation).
It seems that Windows Terminal now enforces that all tabs in the same Terminal Windows runs either elevated or non-elevated. If I from a non-elevated Windows Terminal use Ctrl-Click to open a new profile as elevated, it will spawn a new elevated Terminal Window (or reuse an existing one if I already have Windows Terminal running elevated).
This effectively blocks the use of gsudo in Windows Terminal as far as I can see (since the process should be able to "move" the shell from the un-elevated Terminal session to a new elevated Terminal session).
Gsudo still works fine with shells in their own windows (e.g. a standalone PowerShell or Cmd window) but usage from within Windows Terminal is as far as I can see no longer possible.
On my Windows 10 machine - running Windows Terminal 1.15.2874 (which at time of writing is the latest for Windows 10 and the same as 1.15.2875 on Windows 11), everything works fine - e.g. I can call gsudo from a non-elevated shell in Windows Terminal and elevate the current tab. On the other hand - the Ctrl-Click option to open a shell elevated doesn't work in my Windows 10 Terminal (I get a short display of the hourglass but no new shell appears)
Any thoughts on what is going on - and what potentially could make gsudo + Windows Terminal under Windows 11 work again will be greatly appreciated.
(Tested using latest public gsudo, 1.7.1)
Beta Was this translation helpful? Give feedback.
All reactions