Ensure that lock files that are used when writing files to disk are created in a location that the currently executing user has permissions for #42
Comments
gep13
added
the
Bug
10 tasks
gep13
added a commit
to gep13/NuGet.Client
that referenced
this issue
Jul 14, 2023
We need to be able to run queries, and store the results of the query on disk, in a location that the current user has access to. When we change the `cacheLocation` of the Chocolatey CLI configuration, the location of the lock file used when saving the HTTP query results shouldn't be impacted. This changes in this commit create a new folder to store the lock files that are used when HTTP Cache Queries are persisted to disk. By taking control of this, rather than having this location be controlled by the `cacheLocation` value in the chocolatey.config file, it means that we have greater control over _where_ these files end up, and more importantly, can ensure that the current user has permission to create these files. As a result of these changes, the following folders will now exist on disk: * C:\ProgramData\ChocolateyHttpCache * C:\ProgramData\ChocolateyHttpCacheLocks * C:\Users\<name-of-user>\.chocolatey\http-cache * C:\Users\<name-of-user>\.chocolatey\http-cache-locks NOTE: At some point, in a later scope of work, we may want to consolidate the `Chocolatey`, `Chocolatey GUI`, `ChocolateyHttpCache`, and `ChocolateyHttpCacheLocks`, into one place, rather than having four different locations, but this is regarded as a larger scope of work than is required just now. A new overload for the `ExecuteWithFileLockedAsync` method has been introduced, which allows for setting of the `BasePath` variable, which controls where the lock file is created. This means that we can directly set this from the HttpSource class, while leaving the other lock file logic in place. Within this overload, we ensure to reset the BasePath back to null, so that the next call into this method will re-establish what this should be.
AdmiringWorm
pushed a commit
to gep13/NuGet.Client
that referenced
this issue
Jul 20, 2023
We need to be able to run queries, and store the results of the query on disk, in a location that the current user has access to. When we change the `cacheLocation` of the Chocolatey CLI configuration, the location of the lock file used when saving the HTTP query results shouldn't be impacted. This changes in this commit create a new folder to store the lock files that are used when HTTP Cache Queries are persisted to disk. By taking control of this, rather than having this location be controlled by the `cacheLocation` value in the chocolatey.config file, it means that we have greater control over _where_ these files end up, and more importantly, can ensure that the current user has permission to create these files. As a result of these changes, the following folders will now exist on disk: * C:\ProgramData\ChocolateyHttpCache * C:\ProgramData\ChocolateyHttpCacheLocks * C:\Users\<name-of-user>\.chocolatey\http-cache * C:\Users\<name-of-user>\.chocolatey\http-cache-locks NOTE: At some point, in a later scope of work, we may want to consolidate the `Chocolatey`, `Chocolatey GUI`, `ChocolateyHttpCache`, and `ChocolateyHttpCacheLocks`, into one place, rather than having four different locations, but this is regarded as a larger scope of work than is required just now. A new overload for the `ExecuteWithFileLockedAsync` method has been introduced, which allows for setting of the `BasePath` variable, which controls where the lock file is created. This means that we can directly set this from the HttpSource class, while leaving the other lock file logic in place. Within this overload, we ensure to reset the BasePath back to null, so that the next call into this method will re-establish what this should be.
AdmiringWorm
pushed a commit
to gep13/NuGet.Client
that referenced
this issue
Jul 20, 2023
We need to be able to run queries, and store the results of the query on disk, in a location that the current user has access to. When we change the `cacheLocation` of the Chocolatey CLI configuration, the location of the lock file used when saving the HTTP query results shouldn't be impacted. This changes in this commit create a new folder to store the lock files that are used when HTTP Cache Queries are persisted to disk. By taking control of this, rather than having this location be controlled by the `cacheLocation` value in the chocolatey.config file, it means that we have greater control over _where_ these files end up, and more importantly, can ensure that the current user has permission to create these files. As a result of these changes, the following folders will now exist on disk: * C:\ProgramData\ChocolateyHttpCache * C:\ProgramData\ChocolateyHttpCacheLocks * C:\Users\<name-of-user>\.chocolatey\http-cache * C:\Users\<name-of-user>\.chocolatey\http-cache-locks NOTE: At some point, in a later scope of work, we may want to consolidate the `Chocolatey`, `Chocolatey GUI`, `ChocolateyHttpCache`, and `ChocolateyHttpCacheLocks`, into one place, rather than having four different locations, but this is regarded as a larger scope of work than is required just now. A new overload for the `ExecuteWithFileLockedAsync` method has been introduced, which allows for setting of the `BasePath` variable, which controls where the lock file is created. This means that we can directly set this from the HttpSource class, while leaving the other lock file logic in place. Within this overload, we ensure to reset the BasePath back to null, so that the next call into this method will re-establish what this should be.
AdmiringWorm
pushed a commit
to gep13/NuGet.Client
that referenced
this issue
Jul 20, 2023
We need to be able to run queries, and store the results of the query on disk, in a location that the current user has access to. When we change the `cacheLocation` of the Chocolatey CLI configuration, the location of the lock file used when saving the HTTP query results shouldn't be impacted. This changes in this commit create a new folder to store the lock files that are used when HTTP Cache Queries are persisted to disk. By taking control of this, rather than having this location be controlled by the `cacheLocation` value in the chocolatey.config file, it means that we have greater control over _where_ these files end up, and more importantly, can ensure that the current user has permission to create these files. As a result of these changes, the following folders will now exist on disk: * C:\ProgramData\ChocolateyHttpCache * C:\ProgramData\ChocolateyHttpCacheLocks * C:\Users\<name-of-user>\.chocolatey\http-cache * C:\Users\<name-of-user>\.chocolatey\http-cache-locks NOTE: At some point, in a later scope of work, we may want to consolidate the `Chocolatey`, `Chocolatey GUI`, `ChocolateyHttpCache`, and `ChocolateyHttpCacheLocks`, into one place, rather than having four different locations, but this is regarded as a larger scope of work than is required just now. A new overload for the `ExecuteWithFileLockedAsync` method has been introduced, which allows for setting of the `BasePath` variable, which controls where the lock file is created. This means that we can directly set this from the HttpSource class, while leaving the other lock file logic in place. Within this overload, we ensure to reset the BasePath back to null, so that the next call into this method will re-establish what this should be.
AdmiringWorm
pushed a commit
to gep13/NuGet.Client
that referenced
this issue
Jul 24, 2023
We need to be able to run queries, and store the results of the query on disk, in a location that the current user has access to. When we change the `cacheLocation` of the Chocolatey CLI configuration, the location of the lock file used when saving the HTTP query results shouldn't be impacted. This changes in this commit create a new folder to store the lock files that are used when HTTP Cache Queries are persisted to disk. By taking control of this, rather than having this location be controlled by the `cacheLocation` value in the chocolatey.config file, it means that we have greater control over _where_ these files end up, and more importantly, can ensure that the current user has permission to create these files. As a result of these changes, the following folders will now exist on disk: * C:\ProgramData\ChocolateyHttpCache * C:\ProgramData\ChocolateyHttpCacheLocks * C:\Users\<name-of-user>\.chocolatey\http-cache * C:\Users\<name-of-user>\.chocolatey\http-cache-locks NOTE: At some point, in a later scope of work, we may want to consolidate the `Chocolatey`, `Chocolatey GUI`, `ChocolateyHttpCache`, and `ChocolateyHttpCacheLocks`, into one place, rather than having four different locations, but this is regarded as a larger scope of work than is required just now. A new overload for the `ExecuteWithFileLockedAsync` method has been introduced, which allows for setting of the `BasePath` variable, which controls where the lock file is created. This means that we can directly set this from the HttpSource class, while leaving the other lock file logic in place. Within this overload, we ensure to reset the BasePath back to null, so that the next call into this method will re-establish what this should be.
AdmiringWorm
added a commit
that referenced
this issue
Jul 24, 2023
(#42) Attempt to fix http caching issue when running as non-admin user
gep13
added a commit
that referenced
this issue
Jul 24, 2023
* release/3.4.0: (maint) Update shipped API's (#42) Ensure locks can be created by current user (build) Starting building 3.4.0 on develop branch
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Checklist
What You Are Seeing?
When running Chocolatey CLI as a non-administrator (and when a cacheLocation value is being used that points at a restricted area), for example when being used with Chocolatey Agent for allow for Self-Service), it is not possible to run
choco outdated, or any other Chocolatey CLI commands that query a source, due to the fact that the saving of the HTTP Query Cache result is not possible since the lock file that is generated can't be saved.This happens due to the fact that when the cacheLocation variable is used, pointing at a restricted area, this set the TEMP environment variable for the process to be this value, and this is then used to figure out "where" to write the lock files. This obviously isn't going to work, since a non-elevated user does not have permissions to write into a restricted location, and as a result, the operation fails.
This came up as reported in this issue, where Chocolatey CUI actually crashes when attempting to run
choco outdatedto establish which packages are outdated so that this information can be displayed within the GUI.What is Expected?
It shouldn't matter what context a command is being run in, either elevated or not, the creation of the HTTP Cache files should work, and the lock files should be created close to the cache files, and not require different permissions for it to work correctly.
How Did You Get This To Happen?
Follow the steps outlined in the issue that was raised in the chocolatey/choco repository.
System Details
Operating System: Windows 11
Windows PowerShell Version: 5.1
Chocolatey CLI Version: 2.1.0
Chocolatey Licensed Extension version: 6.1.0
Chocolatey License type (Professional / Business / ?): Business Trial
Terminal/Emulator: PowerShell
Installed Packages
Output Log
Additional Context
No response
The text was updated successfully, but these errors were encountered: