Temp location can change unexpectedly when using System credentials

[teknowledgist]

What You Are Seeing?

The value of $env:Temp when running as SYSTEM changes for the session in which Get-ToolsLocation is first run. (I encountered this problem with Get-ToolsLocation and wrote most of this around that, but really any other script/function that calls Update-SessionEnvironment will create the same problem.)

Running as SYSTEM, the $env:Temp variable is normally C:\Windows\Temp. If the first package to ever use Get-ToolsLocation happens to be running as SYSTEM, the location of $env:Temp changes to C:\Windows\system32\config\systemprofile\AppData\Local\Temp for the duration of the session. This appears to cause some packages to fail (for unknown reasons).

Future sessions have the correct $env:Temp regardless of calls to Get-ToolsLocation.

What is Expected?

$env:Temp shouldn't change (especially in the middle of the ChocolateyInstall.ps1) unless it is requested by the user.

How Did You Get This To Happen? (Steps to Reproduce)

Everyday users won't be running Chocolatey as SYSTEM, but most centralized desktop management software will. To test this manually requires opening cmd or PoSh windows as SYSTEM as follows:

1. Start with a clean Win10 (snapshotted) VM
2. Install Chocolatey
3. Install pstools (or runassystem) package
4. From an elevated command prompt, run pstools /s /i cmd.exe (or pstools /s /i powershell). (If using runassystem, double click and enter either cmd.exe or powershell.)

From the new console window now running as SYSTEM, you can attempt to install the anaconda3 package (choco install anaconda3). It will fail with the new path displaying. (If you try it again, in a new window -- as SYSTEM -- it will work.) (There may be other packages broken by this, but it would be a PITA to test.)

Easier to see the change is to reset the system and:

1. Install the chocolateypowershell utility package

2. Open the chocolateypowershell console (as SYSTEM), check the $env:temp path, run Get-ToolsLocation and again check $env:temp. The output of that is as follows:

   [ChocolateyPS] C:> $env:temp
   C:\Windows\TEMP
   [ChocolateyPS] C:> get-toolslocation
   C:\tools
   [ChocolateyPS] C:> $env:temp
   C:\Windows\system32\config\systemprofile\AppData\Local\Temp

3. If you open a second chocolateypowershell console, and repeat the commands above, $env:temp does not change. (It only changes the first time.)

The problem stems from the Set-Item "Env:$($_)" -Value (Get-EnvironmentVariable -Scope $scope -Name $_) line (line 74) in the Update-SessionEnvironment.ps1 script.

Although C:\Windows\system32\config\systemprofile\AppData\Local\Temp is the $env:temp value for the SYSTEM user, until Update-SessionEnvironment runs (and for the first time only) as SYSTEM, $env:Temp is always the value from the Machine or Process scope. I have no idea why.

I suspect this could be easily fixed by skipping updating environment variables for the User scope when running as SYSTEM. When Chocolatey is run as SYSTEM, clearly the intent is to do machine-wide activities, and there is no reason to see SYSTEM as a "user". On a clean system, the only User scope environment variables under SYSTEM are path, temp, and tmp, and in general, there shouldn't be any new ones for the SYSTEM account because it's not a "normal" account.

Thanks.

(Edit: clarity)

[teknowledgist]

I modified Update-SessionEnvironment in my cloned repository:

teknowledgist@dc9fe3a

I can't submit a PR because I can't sign the CLA (due to a technical problem reason, not legal reasons), but it should work.

[ferventcoder]

Can you see if setting cacheLocation removes this entirely? I'm guessing (without looking) that you are grabbing the current temp and then setting it back?

Is the clahub down? Looks lime we'll need an alternate means of CLA signing. 😢

[teknowledgist]

Actually, I suspect --cache-location may be broken too, although, I suppose my experience with it could be an extended symptom of this issue.

And yes, clahub appears to be down.

[ferventcoder]

@teknowledgist we've just fixed the CLA issue - see #2036.

[stevozilik]

Found this thread as a result of having issues installing anaconda3 with choco in PS DSC. Many other choco packages in the same DSC install fine, except anaconda3. Even tried setting the --cache-location in choco settings, and providing as parameter for installing anaconda3, but the download still goes to C:\WINDOWS\system32\config\systemprofile\AppData\Local\Temp\anaconda3\ and hence installation fails:

Logs:
Install command:
'choco install anaconda3 -y --cache-location='C:\ChocoTemp' --no-progress'
VERBOSE: [[cChocoPackageInstaller]installAnaconda] Package output
Chocolatey v0.10.15 Installing the following packages: anaconda3 By installing you accept licenses for the packages.
anaconda3 v2020.07 [Approved] anaconda3 package files install completed. Performing other installation steps. WARNING:
The Anaconda3 installation can take a long time (up to 30 minutes). WARNING: Please be patient and let it finish.
WARNING: If you want to verify the install is running, you can watch the installer process in Task Manager Downloading
anaconda3 64 bit from 'https://repo.continuum.io/archive/Anaconda3-2020.07-Windows-x86_64.exe' Download of
Anaconda3-2020.07-Windows-x86_64.exe (467.49 MB) completed. Hashes match. Installing anaconda3... WARNING: Setup was
cancelled. ERROR: Running
["C:\WINDOWS\system32\config\systemprofile\AppData\Local\Temp\anaconda3\2020.07\Anaconda3-2020.07-Windows-x86_64.exe"
/S /InstallationType=AllUsers /RegisterPython=1 /AddToPath=0 /D=C:\tools\Anaconda3 ] was not successful. Exit code was
'2'. Exit code indicates the following: Setup was cancelled.. Environment Vars (like PATH) have changed. Close/reopen
your shell to see the changes (or in powershell/cmd.exe just type refreshenv). The install of anaconda3 was NOT
successful. Error while running 'C:\ProgramData\chocolatey\lib\anaconda3\tools\chocolateyinstall.ps1'. See log for
details.

After manually rebooting the VM, the same installation picks up correct cache location and succeeds.