draios / sysdig

Linux system exploration and troubleshooting tool with first class support for containers
http://www.sysdig.com/
Other
7.8k stars 728 forks source link

refactor: bump libs version to 3bcacab26c021bcf70ec2239c27e8b43b3467174 #1876

Closed jasondellaluce closed 2 years ago

jasondellaluce commented 2 years ago

This makes Sysdig compile successfully with the latest changes in falcosecurity/libs.

What is added

This PR adds checks when plugins are loaded from a directory. There used to be no filter about the files opened, so if any non-shared-library file was present in the plugins directory sysdig exited with an error. This now just looks for shared object files (.so suffix, or .dll in Windows). This aims to make the UX better for users and plugin developers.

What is missing

  1. We do not print the init schema and the open parameters of plugins. Doing that requires separating the logic of registration and initialization of plugins in libsinsp, which are still tied together in a single operation in sinsp::register_plugin. This needs to change in the future, but we'll work on it after the upcoming new version of Falco gets released.
  2. Plugin filterchecks are all added to the same filtercheck list (the global g_filterchecks). This breaks part of the plugin system UX contract: it should be possible for two different event sources to have extractable fields with the same name. In Falco, this is guaranteed because rulesets are partitioned by event source, so there is no ambiguity in a filtering condition. On the other hand, sysdig filters are source-agnostic so it's not possible to know which fields can be used in the filtering condition before-hand. Ideally, this can be mitigated by the fact that the library currently do not support having multiple event sources opened at the same time, but this assumption breaks when reading .scap capture files (they can contain events from both syscalls and plugins). As such, the current approach is to add all the extractable fields to the same filtercheck list with no event source partitioning, leaving a degree of ambiguity in case plugins define fields with same name for different event sources (which is expected to be an unlikely collision).