BUG: Cache failure in docker without root when container is immutable #4286
Replies: 6 comments
-
You can set different permissions to the following directories.
We welcome contributions. |
Beta Was this translation helpful? Give feedback.
-
This issue is stale because it has been labeled with inactivity. |
Beta Was this translation helpful? Give feedback.
-
Please remove the stale lifecycle :) |
Beta Was this translation helpful? Give feedback.
-
This issue is stale because it has been labeled with inactivity. |
Beta Was this translation helpful? Give feedback.
-
/remove-lifecycle stale |
Beta Was this translation helpful? Give feedback.
-
converted to issue #5595 |
Beta Was this translation helpful? Give feedback.
-
Description
Hello,
In my CI pipeline, I'm trying to use the Trivy docker image without root permissions to scan tarball artifacts.
In our environment, we maintain an internal copy of the docker image which gets updated once per hour with the latest trivy db, and we place that in the path
/trivycache
and recently I wanted to convert it to non-root.My Dockerfile is below:
As you can see, I have set the permissions to prevent the user account from overwriting the cache directory where the database is currently stored.
I do this for security reasons to protect the db from being overwritten. However, it seems that keeping the db in the cache directory probably not desirable for our use case, as this is also causing the cache to be unwritable, which I think is an error.
I am running this image in my CI pipeline and we don't have a desire to create a redis instance for this purpose, so I am hoping you could provide 2 new flags.
--db-dir
for specifying the path for the trivy db separately from the cache directory.--no-cache
for specifying not to use the cache at all.In our case, the image is intended to be immutable and we won't make use of the fanal cache, hence writing to it is not necessary.
What did you expect to happen?
Expected for the
--cache-dir
to only be used by the vulnerability db, and was not aware of the fanal cache.After investigating and taking a look at harbor issue 16606, I found out that fanal db is the os package cache for Trivy and so Trivy is always trying to write to it during our scans by the pipeline.
What happened instead?
The
--cache-dir
is used for both the vulnerability db and the fanal cache, so when I changed the permissions to root for the whole directory, it prevents non-root trivy from running.Output of run with
-debug
:Output of
trivy -v
:Additional details (base image name, container registry info...):
Beta Was this translation helpful? Give feedback.
All reactions