Skip to content
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

Issue: Environment Variables Always Copying in v2.0.4, Works as Expected in v1.7.1 #224

Open
shawnjag opened this issue Jan 7, 2023 · 3 comments

Comments

@shawnjag
Copy link

shawnjag commented Jan 7, 2023

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

# Behavior in gsudo v2.0.4
gsudo config CopyEnvironmentVariables # CopyEnvironmentVariables "False"
gsudo {Get-ChildItem ENV:} # ENV of InitialUser (My Issue)
gsudo --copyev {Get-ChildItem ENV:} # ENV of InitialUser
gsudo {$profile} # ProfilePath of InitialUser
gsudo --loadProfile {$profile} # ProfilePath of InitialUser

# Behavior in gsudo v1.7.1
gsudo config CopyEnvironmentVariables # CopyEnvironmentVariables "False"
gsudo {Get-ChildItem ENV:} # ENV of ElevatedUser (Expected)
gsudo --copyev {Get-ChildItem ENV:} # ENV of InitialUser
gsudo {$profile} # Profile Path of ElevatedUser
gsudo --loadProfile {$profile} # Loads and returns ProfilePath of ElevatedUser
@gerardog
Copy link
Owner

gerardog commented Jan 9, 2023

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.

@shawnjag
Copy link
Author

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.

@gerardog gerardog added bug Something isn't working and removed bug Something isn't working labels Feb 20, 2023
@gerardog
Copy link
Owner

gerardog commented Mar 13, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants