Running gsudo from mapped drive

[gerardog]

Running gsudo from mapped drive

[gerardog]

Yes, the elevated and non-elevated apps are actually running in isolated logon sessions, with isolated network connections each. Therefore UNC paths (\\server\share\file) may not be accesible if the elevated session doesn't inherit access or has cached credentials for that share.
Also, mapped drives are no longer resolvable from the elevated session, for instance: If you run gsudo and your current directory is a mapped drive like Z: when elevated the Z: drive no longer points us to a valid \\server\share\file path.

This two issues breaks two things:

• One anti-tampering gsudo protection method.
• The current directory may be invalid on the elevated session, so many commands will refuse to run.

So, this issue is non trivial to solve and has ramifications.

Nonetheless, I've managed to make some fix that allows to use gsudo from a mapped or network drive as long as the current directory is NOT a network drive.

For example the following cases are working on my machine after some fixing

C:\> Z:\utils\gsudo.exe netsh interface ipv4 set ...
C:\> \\server\share\gsudo netsh interface ipv4 set ...

(please note the current directory is C:, not z: )

You can preview the fix from this UNSTABLE, unsigned build)

Another workaround would be to copy gsudo to a local folder first...
As a sidenote, you may want to omit the --piped argument and let gsudo decide which mode to use.

[gerardog]

I've done some tests with v0.7 and, in my extremely limited network/scenario, looks like it's working.
I appreciate anyone who can jump in and let me know if this is still and issue.
Thanks.-