Open shawnjag opened 1 year ago
It's true this changed in v2.0. That scenario is now using TokenSwitchMode instead of attached. Worth reading: https://gerardog.github.io/gsudo/docs/how-it-works
But in a nutshell, --copyev
is not working.
As a workaround, until a fix is released: You can make this work per command adding --attached
, or toggle the behaviour with gsudo config ForceAttachedConsole true
.
This was an excellent read, thanks for sharing! I looked through the release tags for anything mentioning environment variables, but didn't think to check the extended documentation.
I think it makes sense that the default functionality mirrors unix sudo in that ENV is only preserved if a flag is passed. However, I hadn't considered a local admin elevating as themselves. Looking forward to a fix.
I wonder if the config options should instead opt in to the tradeoffs. It seems the options with the least downsides - attached vs token switch, comes down to redirection vs preserving environmental variables, that may be easier to pick between than understanding the elevation modes.
But in a nutshell, --copyev is not working.
Oh yes. it is working. But for TokenSwitchMode, but the env vars of the caller are already on the elevated, so it changes nothing. You want the env vars of a freshly elevated process, so lets do attached mode
I think it may be ok for people to use: gsudo config ForceAttachedConsole true
Maybe --loadprofile
/ --NoCopyEv
could map internally to --attached
Issue Description
Despite the config value of CopyEnvironmentVariables or whether --copyev is specified, gsudo v2.0.4 seems to always copy the environment variables from the caller user to the elevated prompt. This was not the case in gsudo v1.7.1. As a result, the PowerShell profile of ElevatedUser does not load upon instantiation.
The config for PowershellLoadProfile and --loadProfile are for InitialUser's profile to be loaded in the elevated prompt, but I want to use ElevatedUser's profile.
Steps to Reproduce