Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New issue related to removing ScaResolver files #1366

Open
nleach999 opened this issue Jul 12, 2024 · 0 comments
Open

New issue related to removing ScaResolver files #1366

nleach999 opened this issue Jul 12, 2024 · 0 comments
Labels
bug Something isn't working

Comments

@nleach999
Copy link
Contributor

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 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

  1. 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.
  2. Execute CxFlow and observe failures on startup.
  3. Make world-readable logs and cache directories in the ScaResolver install directory.
  4. 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.

Environment Details

CxFlow 1.7.0, 1.7.02, 1.6.46

@nleach999 nleach999 added the bug Something isn't working label Jul 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant