This is a followup to Issue #1129. In that issue, the observation was on a CxFlow container. It mentioned that it may have implications running outside a container as well. This issue is it running outside a container.
Please consider concurrency of different execution environments in any future fixes. It is not possible to file a bug that describes in step-by-step detail how to evaluate concurrency edge-cases for all execution environments.
Expected Behavior
I should be able to deploy SCA Resolver on a standalone, non-container machine such that the user id running CxFlow does not own any directories inside the ScaResolver root directory.
Actual Behavior
CxFlow appears to check on startup that the logs directory at the provided ScaResolver path is writable and fails if it is not. The directory for logs is actually configurable in ScaResolver using command line or static yaml, so logs is only a default and could be something else.
Even if the logs directory default were used, it is common practice in non-container deployments to have a tool installed in a directory owned by an administrative account, thus not modifiable by a non-administrative account.
At the end of the scan, CxFlow recursively deletes the logs directory. In a container running ScaResolver in multiple threads OR on a standalone machine running multiple instances of resolver, there could be open files in logs at the time one scan ends.
Reproduction
Install ScaResolver in a directory that is world-readable but can only be written by other users on the machine. Leave the configuration options at default.
Execute CxFlow and observe failures on startup.
Make world-readable logs and cache directories in the ScaResolver install directory.
CxFlow now runs and successfully executes a scan (though it may fail at the end of a successful scan for some reason I have not yet found) and observe it recursively deletes logs with no consideration for other running threads/processes.
Description
This is a followup to Issue #1129. In that issue, the observation was on a CxFlow container. It mentioned that it may have implications running outside a container as well. This issue is it running outside a container.
Please consider concurrency of different execution environments in any future fixes. It is not possible to file a bug that describes in step-by-step detail how to evaluate concurrency edge-cases for all execution environments.
Expected Behavior
I should be able to deploy SCA Resolver on a standalone, non-container machine such that the user id running CxFlow does not own any directories inside the ScaResolver root directory.
Actual Behavior
CxFlow appears to check on startup that the
logsdirectory at the provided ScaResolver path is writable and fails if it is not. The directory for logs is actually configurable in ScaResolver using command line or static yaml, sologsis only a default and could be something else.Even if the
logsdirectory default were used, it is common practice in non-container deployments to have a tool installed in a directory owned by an administrative account, thus not modifiable by a non-administrative account.At the end of the scan, CxFlow recursively deletes the
logsdirectory. In a container running ScaResolver in multiple threads OR on a standalone machine running multiple instances of resolver, there could be open files inlogsat the time one scan ends.Reproduction
logsandcachedirectories in the ScaResolver install directory.logswith no consideration for other running threads/processes.Environment Details
CxFlow 1.7.0, 1.7.02, 1.6.46