falcosecurity
New transformer: `join(<list>, <sep>)`
Motivation
Please take a look at this comment for context.
The join(<list>, <sep>) transformer concatenates the items of a list with a given separator. Its output can be utilized in two primary ways:
- In conditions for filtering.
- In the
output:field of Falco's rule.
One significant use case is generating a string representation of the process lineage, such as join(proc.lineage, "->").
Feature
Implement the join(<list>, <sep>) function with the following specifications:
<list>: A list (i.e., a field withEPF_IS_LIST).<sep>: A string used as a separator.
The transformer should return a concatenated string.
For example, join(proc.env, ";") would return something like SHELL=/bin/bash;SHELL_NEW=/bin/sh;PWD=/home/user HOME=/home/user.
Note: Implementing this transformer requires extending the current syntax to allow more than one argument.
Alternatives
An alternative is not to implement this transformer if all potential use cases can be achieved through other methods. However, implementing this general-purpose transformer could provide greater flexibility in both filtering and output. Therefore, there is no compelling reason not to implement this transformer.
Perhaps we could also support join(string, sep) to fix https://github.com/falcosecurity/libs/issues/1981?
Perhaps we could also support
join(string, sep)to fix #1981?
@FedeDP we should use concat instead, for that use case, see https://github.com/falcosecurity/libs/issues/2025
@therealbobo shared his staging commits with me, and I reviewed them yesterday. Since I am gradually off-boarding from the project, I won’t be able to assist further, but I wanted to share a few observations. There appears to be a mix-up between the join( and concat( functionality and layout, which may indicate a need to re-evaluate the two newly planned transformers.
I strongly recommend implementing the join( transformer as the last feature, and only once we properly expose LIST field types for transformation — meaning a field structure that can be naturally iterated over by the transformer (not a list of several distinct existing fields). Currently, we don’t have this capability, as even fd.types LIST(CHARBUF) effectively remains a PT_CHARBUF field when passed to the transformer. Effectively, the only planned use case so far is the LIST of process ancestor properties here: https://github.com/falcosecurity/libs/issues/2431.
The concat( function should be easier to implement, and it's essentially what @therealbobo has started working on. See the other comment here: https://github.com/falcosecurity/libs/issues/2025#issuecomment-2920596761
After reviewing the relevant source code sections in more detail, allowing a free-form delimiter seems atypical given the strict checks applied in the syntax grammar validation. We may want to consider restricting it to a predefined set of delimiters?
Also thanks @therealbobo for already putting in so much effort into this feature ❤
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale
