Issue: `sudo` doesn't invoke `gsudo` on Scoop installs: "Sudo is disabled on this machine. To enable it, go to the Developer Settings page in the Settings app"

[m4ss1m0g]

Issue Description

With 24H2 sudo alias don't work.
I read and apply gsudo config PathPrecedence True from #346, but doesn't work.

Steps to Reproduce

1. Win 24H2
2. Execute gsudo config PathPrecedence True
3. Close all terminal
4. Start new terminal
5. try sudo
6. Error popup Sudo is disabled on this machine. To enable it, go to the Developer Settings page in the Settings app

Context:

• Windows version: 24H2

• gsudo version: v2.5.1

[gerardog]

Note to newcomers:

If you get Sudo is disabled on this machine... is because you are invoking Microsoft sudo. You can use the gsudo keyword, or try gsudo config PathPrecedence true to force the sudo alias towards gsudo. The following ticket explains an scenario where PathPrecedence is/was not working as intended for those who installed gsudo with Scoop.

---

Have you restarted your consoles after gsudo config PathPrecedence True? That would be enough, but if still no good you can try also to log-out and log-in again.
If still not working would you please then open cmd.exe and run path and paste the results here?
Thanks

[m4ss1m0g]

I have restarted the pc but no luck, here is the path.

PATH=C:\Users\massimo\scoop\apps\gsudo\current;C:\Program Files (x86)\Common Files\Oracle\Java\java8path;C:\Program Files (x86)\Common Files\Oracle\Java\javapath;C:\Program Files\Microsoft MPI\Bin;C:\Program Files (x86)\VMware\VMware Workstation\bin;C:\ProgramData\scoop\shims;C:\Program Files\shims;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0;C:\WINDOWS\System32\OpenSSH;C:\Program Files\dotnet;C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\170\Tools\Binn;C:\Program Files (x86)\Microsoft SQL Server\150\DTS\Binn;C:\Program Files (x86)\Microsoft SQL Server\150\Tools\Binn;C:\Program Files\Microsoft SQL Server\150\Tools\Binn;C:\Program Files\Microsoft SQL Server\150\DTS\Binn;C:\Program Files (x86)\dotnet-core-uninstall;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Program Files\PowerShell\7;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0;C:\WINDOWS\System32\OpenSSH;C:\Program Files\Docker\Docker\resources\bin;C:\Users\massimo\scoop\apps\nodejs-lts\current\bin;C:\Users\massimo\scoop\apps\nodejs-lts\current;C:\Users\massimo\scoop\apps\vscode\current\bin;C:\Users\massimo\scoop\apps\openssl\current\bin;C:\Users\massimo\scoop\apps\gsudo\current;C:\Users\massimo\scoop\shims;C:\Users\massimo\AppData\Local\Microsoft\WindowsApps;C:\ProgramData\AppGet\bin;C:\Users\massimo.dotnet\tools;C:\Users\massimo.dotnet\tools;C:\msys64\ucrt64\bin;C:\Users\massimo\AppData\Local\Microsoft\WindowsApps

here is the gsudo config

# CacheMode: Defines how gsudo credentials cache works: Auto, Explicit (default), Disabled
# CacheDuration: Defines how long (HH:MM:SS) the credentials cache will be valid if idle. Use 'Infinite' for no expiration
# LogLevel: Defines the verbosity of the log. (Valid values: All, Debug, Info, Warning, Error, None)
# NewWindow.Force: Always elevate in new window. (Equivalent to --new)
# NewWindow.CloseBehaviour: When elevating in a new window, defines what happens when the process ends: OsDefault (let the window auto-close), KeepShellOpen or PressKeyToClose
# Prompt: CMD Prompt to be used when gsudo uses standard mode
# PipedPrompt: CMD Prompt to be used when gsudo uses piped mode
# ForceAttachedConsole: Forces gsudo to use Attached mode. Can fix some very specific problems. Same as --attached
# ForcePipedConsole: Forces gsudo to use legacy piped mode. Not recommended
# ForceVTConsole: Forces gsudo to use VT mode. Experimental. Same as --vt
# CopyEnvironmentVariables: Only applies to Attached Mode. Forces copying caller's env variables to the elevated context. Same as --CopyEv
# CopyNetworkShares: Reconnect network shares on the elevated context. Same as --CopyNs
# PowerShellLoadProfile: Loads the PowerShell profile when elevating PowerShell commands. Same as --LoadProfile
# SecurityEnforceUacIsolation: Elevates but with the input handle closed. More secure, but less convenient. Same as --disableInput
# ExceptionList: List of executables with some issues so they will be started with "cmd /c executable"
# PathPrecedence: Prioritize gsudo over Microsoft Sudo in the PATH environment variable

CacheMode = "Explicit"                            (default)
CacheDuration = "00:05:00"                        (default)
LogLevel = "Info"                                 (default)
NewWindow.Force = "False"                         (default)
NewWindow.CloseBehaviour = "OsDefault"            (default)
Prompt = "$p$e[1;31m# $e[0m"                      (default)
PipedPrompt = "$P# "                              (default)
ForceAttachedConsole = "False"                    (default)
ForcePipedConsole = "False"                       (default)
ForceVTConsole = "False"                          (default)
CopyEnvironmentVariables = "False"                (default)
CopyNetworkShares = "False"                       (default)
PowerShellLoadProfile = "False"                   (default)
SecurityEnforceUacIsolation = "False"             (default)
ExceptionList = "notepad.exe;powershell.exe;whoami.exe;vim.exe;nano.exe;" (default)
PathPrecedence = "True"                           (global)

[RuiNtD]

It doesn't work with Scoop because sudo.exe is in scoop\shims, but PathPrecedence puts scoop\apps\scoop\current at the start of PATH, which only contains gsudo.exe and not sudo.exe. Unless @gerardog changes the behavior of PathPrecendence to correctly handle Scoop, the easiest solution is to just reinstall gsudo with WinGet, which does create a symlink from sudo.exe to gsudo.exe
EDIT: You'll also have to scoop uninstall gsudo, since it's now the first in PATH. 😅

[m4ss1m0g]

Thanks, @RuiNtD I created a symlink into gsudo\current dir with mklink sudo.exe gsudo.exe and it now works. The drawback is that at each update I must recreate the link, I hope Gerardo can fix this.

[RuiNtD]

An alternative is to make a folder somewhere on your drive containing only a symlink from sudo.exe to scoop\apps\gsudo\current\gsudo.exe and put that at the start of PATH.

As for adding a fix, gsudo should probably check for the existence of sudo.exe anyways when enabling PathPrecedence, since it's the whole point of the setting, and since it already asks for admin to change the PATH, it can create a symlink at that time as well.

[m4ss1m0g]

Maybe @gerardog can add a File.CreateSymbolicLink when set PathPrecedence if path contains "scoop".

Another approach can be to modify the post_install on gsudo scoop script, but I think this is out of the control of @gerardog.

Another approach is to place scoop/shims as the first path, but I don't know if there are any counter-indications.

[dmuiX]

Have you restarted your consoles after gsudo config PathPrecedence True? That would be enough, but if still no good you can try also to log-out and log-in again. If still not working would you please then open cmd.exe and run path and paste the results here? Thanks

Definitely Worked for me
Thanks.

[soredake]

Same problem.

After rebooting:

❯ where.exe sudo
C:\Windows\System32\sudo.exe
C:\Users\user\scoop\shims\sudo.exe
❯ echo $env:PATH
C:\Program Files\PowerShell\7;C:\Program Files (x86)\oh-my-posh\bin\;C:\Users\user\scoop\apps\gsudo\current;C:\Program Files (x86)\VMware\VMware Workstation\bin\;C:\Program Files\Eclipse Adoptium\jdk-17.0.14.7-hotspot\bin;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\WINDOWS\System32\OpenSSH\;C:\Program Files\dotnet\;C:\ProgramData\chocolatey\bin;C:\Program Files (x86)\dotnet\;C:\tools\BCURRAN3;C:\Program Files (x86)\oh-my-posh\bin;C:\Program Files\WireGuard\;C:\Program Files\FileBot\;C:\Program Files\WinGet\Links;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\WINDOWS\System32\OpenSSH\;C:\Program Files\PowerShell\7\;C:\ProgramData\chocolatey\lib\mpvio.install\tools;C:\Program Files\nodejs\;C:\Program Files\Git\cmd;C:\Users\user\scoop\apps\gsudo\current;C:\Users\user\scoop\apps\nircmd\current;C:\Users\user\AppData\Local\Programs\Python\Python312\Scripts\;C:\Users\user\AppData\Local\Programs\Python\Python312\;C:\Users\user\AppData\Local\Programs\oh-my-posh\bin\;C:\Users\user\AppData\Local\Programs\Python\Launcher\;C:\Users\user\scoop\shims;C:\Users\user\AppData\Local\Microsoft\WindowsApps;C:\Program Files\Oracle\VirtualBox;C:\Users\user\AppData\Local\Programs\Microsoft VS Code\bin;C:\Users\user\AppData\Local\Microsoft\WinGet\Links;C:\Users\user\AppData\Local\Programs\Komac\bin;c:\users\user\.local\bin;C:\Users\user\AppData\Roaming\npm;C:\Users\user\AppData\Local\Microsoft\WindowsApps;C:\Users\user\AppData\Local\Microsoft\WinGet\Packages\thebookisclosed.Vive_Microsoft.Winget.Source_8wekyb3d8bbwe;C:\Users\user\AppData\Local\Microsoft\WinGet\Packages\Google.PlatformTools_Microsoft.Winget.Source_8wekyb3d8bbwe\platform-tools;C:\Program Files\Multipass\bin
❯ sudo --version
sudo 1.0.1
❯ gsudo --version
gsudo v2.6.0 (Branch.tags-v2.6.0.Sha.8067a30b9a83dc3ba318c0007644d1878773abec)
Copyright(c) 2019-2022 Gerardo Grignoli and GitHub contributors

[RuiNtD]

Same problem.

Read the above comments. PathPrecedence doesn't work on a Scoop install since it doesn't contain a symlink from sudo.exe to gsudo.exe. You can either create a symlink in a new folder pointing a sudo.exe to scoop\apps\gsudo\current\gsudo.exe and add it to path, or just:

scoop uninstall gsudo
winget install gerardog.gsudo
gsudo config PathPrecedence True

[gerardog]

Thank you all for identifying the problem and proposing a good solution! I've implemented it and should be part of the next release (v2.6.1)

With the new release, PathPrecedence will also work on scoop.

If you want to test it right now, can try the latest unsigned build, scroll down to Artifacts

[RuiNtD]

Thank you all for identifying the problem and proposing a good solution! I've implemented it and should be part of the next release (v2.6.1)

With the new release, PathPrecedence will also work on scoop.

Looks like you went with creating the symlink when updating the config. My only concern is that the symlink in PATH will become outdated anytime gsudo is updated.

[IDisposable]

That's why I suggested pointing at the Current junction #390

[RuiNtD]

Another solution could be to include a shim just pointing to gsudo.exe?

[gerardog]

My only concern is that the symlink in PATH will become outdated anytime gsudo is updated.

Ouch! You got a point. @RuiNtD

Another solution could be to include a shim just pointing to gsudo.exe?

Oh I hate shims (they are worse than symlinks cause they produce other issues) but scoop is already using shims for the sudp alias... (cause Symlinks require elevation in win10 without dev mode).

So, this could work. But the fix would be in scoop's pkgs repo, possibly calling the shim function in post_install. Would this work for all?

Thanks for the suggestion!
(Also, now the sudo shim in scoops\shim would be redundant.)

That's why I suggested pointing at the Current junction #390

@IDisposable That PR affects .MSI installers which are not affected by this bug. Only portable and scoop installs are affected by this one.

And we can't create file symlinks in Scoop (it requires elevation in Windows 10 <= without dev mode),... That's what causes this issue.