Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Treat plugin fields like other sinsp fields (all evt types)
In #74 we pushed down some code from falco that determines the sinsp event types that are applicable for a given filter. The set of event types starts with "all events", and as the filter condition is parsed, including logical operators like "and", "or", "not", etc, the set of event types is changed, honoring the logical operators. For example, for a condition proc.name=nginx, the filter is applicable for all event types, as the condition does not include any evt.type field. For a more complicated condition like evt.type=openat and proc.name=nginx, the first field restricts the event types to openat, which is logical anded against all event types from proc.name, resulting in only the event type openat. With the introduction of plugins, there's also a need to segregate plugin-related filterchecks from non-plugin-related filterchecks by event source, but that's handled at a higher level, using a notion of filter factories and formatter factories (#77). The bug is that plugin filtercheck fields like ct.name, json.value were mistakenly being restricted to only the plugin event PPME_PLUGINEVENT_E. This was being mistakenly inverted when conditions had a "not" operator, with the result being that they did not run on any event types at all. The fix is to treat plugin fields as working with all event types, just like almost all other fields like proc.name, etc. are. This allows the logical operators to combine event type sets properly. This, along with other small changes in falco + plugins, fixes falcosecurity/plugins#56. Signed-off-by: Mark Stemm <mark.stemm@gmail.com>
- Loading branch information