-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
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)
// 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 😉 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
whoops - @nathpete-msft
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
auto processToken{ wil::open_current_access_token(TOKEN_QUERY | TOKEN_DUPLICATE) };
That does it!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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)