falcoctl install/follow fails if "plugins-dir" and/or "rulesfiles-dir" does not exist
alacuku opened this issue ยท 7 comments
What happened:
When installing a plugin artifact falcoctl
fails because the rulesfiles-dir
does not exist:
falcoctl artifact install k8saudit --plugins-dir ./
ERRO rulesfiles-dir: /etc/falco doesn't exists
What you expected to happen:
The command should fail only if the plugins-dir
does not exist or is not writable by the tool. In this case, the command should run successfully and not fail because the rulesfiles-dir
is not needed.
How to reproduce it (as minimally and precisely as possible):
Make sure that the default(/etc/falco) "rulesfiles-dir" does not exist and run the following command:
falcoctl artifact install k8saudit --plugins-dir ./
Anything else we need to know?:
The current behavior was introduced in the following PR: #247.
Hi @alacuku, I'm thinking about what would be the better behaviour in case there are dependencies to be solved.
For example, when installing a ruleset which depends on a plugin, and not customizing the plugins path:
falcoctl artifact install --rulesfiles-dir /etc/falcoct/rules.d/ k8saudit-rules --resolve-deps=true
I would expect that the command would notify me that the default /usr/share/falco/plugins
does not exist / is not writable by the user. But maybe I'm missing something.
Update: it could be convenient to avoid the check when on existence/writeability of the directory, only when the relevant type is allowed. For example this wouldn't incur in an error:
$ rm -rf /tmp/falcoctl/plugins
$ mkdir /tmp/falcoctl/rules
$ falcoctl \
--config ~/.config/falcoctl.yaml \
artifact install k8saudit-rules \
--resolve-deps=false \
--rulesfiles-dir=/tmp/falcoctl/rulesdir \
--plugins-dir=/tmp/falcoctl/plugins \
--allowed-types='rulesfile'
Falcoctl should check for destination directories only when we are sure those directories will be used. We should have a helper function that checks if a directory exists and is writable and call it in the relevant paths in falcoctl.
Hi @maxgio92! Are you working on this? Otherwise I'd be happy to help!
Hi @therealbobo, please, be my guest :-)
/assign
I took a look at this issue: I think the best approach could be to lazy check on every pull. This way we'll cover the case in which the directory is removed in a second moment. WDYT?
I think it makes sense @therealbobo