microsoft
AppLocker prevents package installation
Brief description of your issue
- our company has AppLocker enabled with an allow-list of directories that executables can be started
- when installing a package (like Git.Git) it results in the following error (manually translated into english)
Installer-Hash successfully validated Package installation is going to start... Unexpected error during execution of command: 0x8007029c : An assert error has occured.
- the applocker event log states
The execution from %OSDRIVE%\USERS\SOMEUSER\APPDATA\LOCAL\PACKAGES\MICROSOFT.DESKTOPAPPINSTALLER_8WEKYB3D8BBW E\TEMPSTATE\WINGET\GIT.GIT.2.32.0.EXE was blocked.
Expected behavior
We should be able to set the package directory where the packages are downloaded and executed.
A option within winget settings should be added to override the default location.
Actual behavior
With AppLocker enabled, we can not use winget, because executables cannot be run inside the users profile path.
Environment
Windows Package Manager v1.0.11451
Windows: Windows.Desktop v10.0.19042.1052
Paket: Microsoft.DesktopAppInstaller v1.11.11451.0
We have a change coming in the next release to change the download location to %TEMP% https://github.com/microsoft/winget-cli/pull/1146.
We have a change coming in the next release to change the download location to %TEMP% https://github.com/microsoft/winget-cli/pull/1146.
This would not help us as the temp directory is the main directory for malicious scripts and programs and therefore also blocked by AppLocker.
Like I said, everyone with AppLocker needs a configuration option for the path from which the exe, msi and so on will be started.
@michha we've identified this Issue as a duplicate of another one that already exists. This specific instance is being closed in favor of tracking the concern over on the referenced Issue. Thanks for your report! Be sure to add your 👍 to the other issue to help raise the priority.
@denelon I stubled across this issue as well. In my opinion this is not the same as #970. This issue is about the temp folder that is used by winget to download and run the installer. #970 is about the target directory of the software to be installed into. Both of these locations are blocked by AppLocker software, since all of them base in %LOCALAPPDATA%. The applications are installed in \Programs\ and the installer is run from \Temp.
As a target install directory I can image people might want to install into the C:\Program Files\ folder, or something else. This location a user will not want to use for the temporary data stored by winget during installation, which this issue is about. I can image that you'd might to set this folder to C:\Temp\ or something different.
@paalders I'll discuss this with the team. If there aren't any major blocking reasons associated with a user specified location, I'll re-open the Issue and mark the appropriate comments "No longer applicable". If not, I'll share the reasons so we can look for alternative solutions. One of the benefits we might lose is the ability to use the "Disk Cleanup" behavior associated with "Temporary Files".
We still have some concerns regarding long path names, but it looks like this is a different ask than what I initially understood.
@denelon Whats the status about this issue. We are still struggling with winget because we cannot set the temporary folder for the package content.
We will be tackling standalone .exe and .zip packages in 1.3. I'm highly expecting we will be looking at how we handle paths for those types of packages. It will likely make sense to bring this in with that effort. We will also need to include the information via winget --info as logs from some installers tend to get placed in the directory the installer runs from.
@michha this didn't make the cut for 1.3, and .zip will be moved to 1.4 as well. I'll put this into the 1.4 milestone to see if the team can fit this in.
Sadly, no. We did get .zip support included in 1.4, but there wasn't enough time to look at supporting alternate paths for where we download and run installers from.
In the latest 1.5 preview I couldnt find any reference to this issue. Will there be a fix for this issue in 1.5?
We really need an environment variable to give winget a hint for the temporary folder it should use.
@michha take a look at the Roadmap to see how we generally prioritize work. This Issue simply doesn't have enough "demand" yet to move up very high in the backlog. I've moved it into the v.next milestone rather than the backlog to see if there is more interest or need for this work.
