Always create a new environment block before we spawn a process#7243
Conversation
This commit ensures that we always furnish a new process with the cleanest, most up-to-date environment variables we can. There is a minor cost here in that WT will no longer pass environment variables that it itself inherited to its child processes. This could be considered a reasonable sacrifice. It will also remove somebody else's TERM, TERM_PROGRAM and TERM_PROGRAM_VERSION from the environment, which could be considered a win. Related to #1125 (but it does not close it or resolve any of the other issues it calls out.) Fixes #7239 Fixes #7204 ("App Paths" value creeping into wt's environment)
| // defaults to the current environment. | ||
| // Return Value: | ||
| // - S_OK if we succeeded, or an appropriate HRESULT for failing | ||
| HRESULT Microsoft::Console::Utils::UpdateEnvironmentMapW(EnvironmentVariableMapW& map) noexcept |
There was a problem hiding this comment.
It seems a bit strange to take std::optional<void*> and then treat nullptr as equivalent to std::nullopt. I don't see std::optional<T*> anywhere else in the source tree. But perhaps it makes sense if you consider nullptr an invalid argument here.
There was a problem hiding this comment.
I concur - why isn't the parameter just a EnvironmentBlockPtr that we compare to nullptr to check if it was provided?
|
I'm cool with this as-is, but I think I want to hear the |
|
So, that's a fair question and one for which I don't really have a good answer. I'm fine just dropping it to |
|
There, I switched it to a |
|
I don't see any |
|
Well, I decided that an optional-not-null-void* was the same as a void* so I cut out the middle party 😉 |
miniksa
left a comment
There was a problem hiding this comment.
While I think the 3-way merge is probably the ideal solution, I can see it being prohibitively expensive to figure out before we know that it's warranted.
Making the 0-way merge of a fresh block solves the immediate problem. And I think it would/will be minor to add a follow-on of "which vars would you like to inherit and stomp in the new block" if that becomes necessary (at a much lower cost than a full merge resolution).
So I'm OK with this.
|
Hello @DHowett! Because this pull request has the p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (
|
| EnvironmentBlockPtr Microsoft::Console::Utils::CreateEnvironmentBlock() | ||
| { | ||
| void* newEnvironmentBlock{ nullptr }; | ||
| if (!::CreateEnvironmentBlock(&newEnvironmentBlock, GetCurrentProcessToken(), FALSE)) |
There was a problem hiding this comment.
@Nathpete can you test what happens if you replace GetCurrentProcessToken with..
auto processToken{ wil::open_current_access_token() };
CreateEnv(...processToken.get()...)If that doesn't restore USERNAME, can you try passing TOKEN_QUERY|TOKEN_DUPLICATE as the first arg to open_current_acc?
There was a problem hiding this comment.
auto processToken{ wil::open_current_access_token(TOKEN_QUERY | TOKEN_DUPLICATE) };
That does it!
There was a problem hiding this comment.
Ugh, I am surprised CreateEnvironmentBlock behaves that way. Tested:
NULL=> USERNAME=SYSTEMGetCurrentProcessToken()=> no USERNAMEGetCurrentThreadEffectiveToken()=> no USERNAMEOpenProcessToken(GetCurrentProcess(), TOKEN_QUERY | TOKEN_QUERY_SOURCE, &hToken)=> no USERNAMEOpenProcessToken(GetCurrentProcess(), TOKEN_QUERY | TOKEN_DUPLICATE, &hToken)=> correct USERNAME(HANDLE)0x123456=> error 6
Perhaps it is because GetCurrentProcessToken() lacks TOKEN_DUPLICATE access.
There was a problem hiding this comment.
You know, you're probably right about that last bit. That makes sense.
At least there's a nice WIL helper for us to get our current effective access token 😄
This fixes a regression in environment variable loading introduced as part of the new environment block creation that prevents some system-defined, volatile environment variables from being defined. ## References #7243 (comment) ## Validation Steps Performed Manually verified locally. Closes #7399
This fixes a regression in environment variable loading introduced as part of the new environment block creation that prevents some system-defined, volatile environment variables from being defined. ## References #7243 (comment) ## Validation Steps Performed Manually verified locally. Closes #7399 (cherry picked from commit 64f10a0)
|
🎉 Handy links: |
This fixes a regression in environment variable loading introduced as part of the new environment block creation that prevents some system-defined, volatile environment variables from being defined. ## References microsoft/terminal#7243 (comment) ## Validation Steps Performed Manually verified locally. Closes #7399
Revert "Fix environment block creation (#7401)" This reverts commit 7886f16. (cherry picked from commit e46ba65) Revert "Always create a new environment block before we spawn a process (#7243)" This reverts commit 849243a. References #7418 (cherry picked from commit 4204d25) (cherry picked from commit f8e8572)
Revert "Fix environment block creation (#7401)" This reverts commit 7886f16. (cherry picked from commit e46ba65) Revert "Always create a new environment block before we spawn a process (#7243)" This reverts commit 849243a. References #7418 (cherry picked from commit 4204d25) (cherry picked from commit f8e8572) (cherry picked from commit cb4c4f7)
Revert "Fix environment block creation (#7401)" This reverts commit 7886f16. (cherry picked from commit e46ba65) Revert "Always create a new environment block before we spawn a process (#7243)" This reverts commit 849243a. References #7418 (cherry picked from commit 4204d25) (cherry picked from commit f8e8572) (cherry picked from commit cb4c4f7) (cherry picked from commit afb0cac)
Revert "Fix environment block creation (#7401)" This reverts commit 7886f16. (cherry picked from commit e46ba65) Revert "Always create a new environment block before we spawn a process (#7243)" This reverts commit 849243a. References #7418 (cherry picked from commit 4204d25) (cherry picked from commit f8e8572) (cherry picked from commit cb4c4f7) (cherry picked from commit afb0cac) (cherry picked from commit b25dc74)
|
@DHowett Hello. Has this issue regressed? I'm on WT version 1.11.2921.0 and I'm having the same problem albeit using the "setx /M" command to update the system wide env variable. Is this different? |
|
@kpentaris, these changes have been repeatedly reverted from stable releases of Windows Terminal, e.g. in 616a71d for Windows Terminal 1.11.2921.0. If you want this feature, use Windows Terminal Preview for now. I guess it will continue this way until the Windows PowerShell (x86) incompatibility #7418 is fixed somehow. |
|
@kpentaris I believe we never ended up shipping this to stable, and it's only in the Preview builds of the Terminal |
|
D'oh! It's actually mentioned in the latest commit... Very well, hopefully at some point this is fixed. |
Revert "Fix environment block creation (#7401)" This reverts commit 7886f16. (cherry picked from commit e46ba65) Revert "Always create a new environment block before we spawn a process (#7243)" This reverts commit 849243a. References #7418 (cherry picked from commit 4204d25) (cherry picked from commit f8e8572) (cherry picked from commit cb4c4f7) (cherry picked from commit afb0cac) (cherry picked from commit b25dc74)
Revert "Fix environment block creation (#7401)" This reverts commit 7886f16. (cherry picked from commit e46ba65) Revert "Always create a new environment block before we spawn a process (#7243)" This reverts commit 849243a. References #7418 (cherry picked from commit 4204d25) (cherry picked from commit f8e8572) (cherry picked from commit cb4c4f7) (cherry picked from commit afb0cac) (cherry picked from commit b25dc74) (cherry picked from commit 5f7c66b)
Revert "Fix environment block creation (#7401)" This reverts commit 7886f16. (cherry picked from commit e46ba65) Revert "Always create a new environment block before we spawn a process (#7243)" This reverts commit 849243a. (cherry picked from commit 4204d25) (cherry picked from commit f8e8572) (cherry picked from commit cb4c4f7) (cherry picked from commit afb0cac) (cherry picked from commit b25dc74) (cherry picked from commit 5f7c66b) Fixes #7418
This commit ensures that we always furnish a new process with the
cleanest, most up-to-date environment variables we can. There is a minor
cost here in that WT will no longer pass environment variables that it
itself inherited to its child processes.
This could be considered a reasonable sacrifice. It will also remove
somebody else's TERM, TERM_PROGRAM and TERM_PROGRAM_VERSION from the
environment, which could be considered a win.
I validated that GetCurrentProcessToken returns a token we're
technically able to use with this API; it is roughly equivalent to
OpenProcessToken(GetCurrentProcess) in that it returns the current
active access token (which is what CreateEnvironmentBlock wants.)
There's been discussion about doing a 3-way merge between WT's
environment and the new one. This will be complicated and I'd like to
scream test the 0-way merge first ;P
Related to #1125 (but it does not close it or resolve any of the other
issues it calls out.)
Fixes #7239
Fixes #7204 ("App Paths" value creeping into wt's environment)