choco icon indicating copy to clipboard operation
choco copied to clipboard
verified publisher icon chocolatey

Paths for "TMP" & "TEMP" seem to be overriden, when running "refreshenv" as "SYSTEM"

Open michiexe opened this issue 6 months ago • 1 comments

Checklist

  • [x] I confirm there are no unresolved issues reported on the Chocolatey Status page.
  • [x] I have verified this is the correct repository for opening this issue.
  • [x] I have verified no other issues exist related to my problem.
  • [x] I have verified this is not an issue for a specific package.
  • [x] I have verified this issue is not security related.
  • [x] I confirm I am using official, and not unofficial, or modified, Chocolatey products.

What You Are Seeing?

Issue description

The problem seems to be, that when the "refreshenv"/"Update-SessionEnvironment"-command is run from a PowerShell session, that was started from the "SYSTEM"-user/-context, that the values of the "TMP" & "TEMP" environment variables are being overriden in the current PowerShell session. The changed values only affect the current PowerShell session.

The values of "TMP" & "TEMP" in the PowerShell session seem to be set to: "C:\Windows\system32\config\systemprofile\AppData\Local\Temp"

Additional Information

I confirmed this issue to arise on the following chocolatey versions:

  • 2.4.3
  • 2.4.1
  • 2.3.0

I confirmed this issue to not arise in the following chocolatey versions:

  • 1.4.0
  • 2.0.0
  • 2.2.2

My educated guess is, that the issue was created somewhere between the cocolatey versions 2.2.2 and 2.3.0.

What is Expected?

The values of "TMP" & "TEMP" should not be changed from "C:\Windows\TEMP" to "C:\Windows\system32\config\systemprofile\AppData\Local\Temp" in the current PowerShell session.

How Did You Get This To Happen?

Important note:

I have created two PowerShell scripts to make it easy to reproduce the issue as my actual use-case is too complicated to reproduce otherwise. These scripts reprocude the root cause of the issue I am experiencing.

I cannot confirm or deny, if the issue also arises, when the same actions are not executed in a Windows-Task and instead run as "SYSTEM" directly.

run-test.txt setup-test.txt

I believe this issue might also have a similar cause as: #2044

Steps to reproduce:

  1. Create a folder somewhere. (I created mine at "C:\gitIssueTest")
  2. Download the files I have attached (look above) and place them in the folder you just created.
  3. Screen the two files!
  4. After screening the files and confirming they are non-malicious, rename their file-endings from ".txt" to ".ps1".
  5. Open an elevated (!) PowerShell session and navigate to the created folder.
  6. Run "setup-test.ps1" via .\setup-test.ps1 (only once!). This creates a Windows-Task, which itself executes the "run-test.ps1" script. This is neccessary, because this is the way I ran into the issue.
  7. In the same PowerShell session run Start-ScheduledTask -TaskName "GitHubIssueTest".
  8. Refresh the contents of the folder you have created earlier. You should find a file "output.txt"
  9. Open the "output.txt" file. It should now contain this text:

Transcript started, output file is C:\gitIssueTest\output.txt Values before running refreshenv/Update-SessionEnvironment

TEMP-path: C:\Windows\TEMP TMP-path: C:\Windows\TEMP

Refreshing environment variables from the registry for powershell.exe. Please wait... Finished

TEMP-path: C:\Windows\system32\config\systemprofile\AppData\Local\Temp TMP-path: C:\Windows\system32\config\systemprofile\AppData\Local\Temp

  1. You can now remove the Windows-Task by running Unregister-ScheduledTask -TaskName "GitHubIssueTest" -Confirm:$false. The folder you created earlier can also be deleted now.

System Details

  • Operating System: 10.0.20348.0
  • Windows PowerShell version:
Name                           Value
----                           -----
PSVersion                      5.1.20348.2849
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.20348.2849
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
  • Chocolatey CLI Version: 2.4.3
  • Chocolatey Licensed Extension version: Chocolatey v2.4.3
  • Chocolatey License type: ?
  • Terminal/Emulator: Windows PowerShell

Installed Packages

Chocolatey v2.4.3
autologon 3.10.0.20200924
chocolatey 2.4.3
chocolatey-compatibility.extension 1.0.0
chocolatey-core.extension 1.4.0
chocolatey-windowsupdate.extension 1.0.5
dotnet-6.0-desktopruntime 6.0.26
KB2919355 1.0.20160915
KB2919442 1.0.20160915
KB2999226 1.0.20181019
KB3033929 1.0.5
KB3035131 1.0.3
KB3063858 1.0.0
keystore-explorer.portable 5.5.3
notepadplusplus 8.6.2
notepadplusplus.install 8.6.2
openjdk17 17.0.2.20220913
OpenSSL.Light 3.1.4
Temurin17 17.0.10
vcredist140 14.38.33135
19 packages installed.

Output Log

Not applicable, as no log is created.

Additional Context

Additional information:

I have also skimmed through the sources and I presume, that the issue may be contained in the UpdateSession method/function in this file: Chocolatey.PowerShell/Helpers/EnvironmentHelper.cs I cannot explain how, but at some point SYSTEM seems to have to be be added to scopeList, as far as I can understand the code. The source-code is also a bit weird, as EnvironmentVariables contains only the "names"/"keys" of the environment variables, apart from the field System, which is used as the value in the comparison in the EnvironmentHelper, which is a bit inconsistent.

var computerName = GetVariable(cmdlet, EnvironmentVariables.ComputerName, EnvironmentVariableTarget.Process);

// User scope should override (be checked after) machine scope, but only if we're not running as SYSTEM
if (userName != computerName && userName != EnvironmentVariables.System)
{
    scopeList.Add(EnvironmentVariableTarget.User);
}

michiexe avatar Jun 04 '25 15:06 michiexe

To vote for this issue, please add a 👍 emoji to the issue description. Votes in comments are not recorded.

github-actions[bot] avatar Jun 04 '25 15:06 github-actions[bot]

Thank you for reporting this. I didn't get the exact same results as you when run in a Vagrant box, but I got a close approximation (the temp variable changed after refreshenv was run, which I don't think is the desired behaviour). I was also able to reproduce this exactly by using psexec and running psexec -s -i powershell.exe:

Image

corbob avatar Sep 09 '25 17:09 corbob

Huh, that's curious. And yeah, although it is not quite the same way to get to the issue, it appears to result in similar/the same symptoms. I don't know if you were referring to the left PowerShell Window, when you said:

[...] but I got a close approximation (the temp variable changed after refreshenv was run, which I don't think is the desired behaviour).

but the environment variables seem to change in that window too, from ...\Temp\1 to ...\Temp, which seems a bit weird, as well as in the right window changing to the exact path I originally reported when I opened the issue. So maybe there is something bigger going on, than just setting the variables to C:\Windows\system32\config\systemprofile\AppData\Local\Temp in some instances.

Also, thank you for taking the time to investigate this issue a bit further!

michiexe avatar Sep 09 '25 19:09 michiexe

I think I've tracked down what the issue is, and have opened PR #3787 for it. Essentially, the username when you're running as SYSTEM is actually COMPUTERNAME$.

corbob avatar Sep 09 '25 19:09 corbob

:tada: This issue has been resolved in version 2.6.0 :tada:

The release is available on:

Your GitReleaseManager bot :package: :rocket:

choco-bot avatar Dec 01 '25 10:12 choco-bot