Chisels don't respect display filters

[gianlucaborello]

sysdig -d -c echo_fds fd.port = 80

Will not respect the filter, and will show all the traffic anyway.

[Hefeweizen]

Solving this problem effectively requires understanding the intent of display_filter and chisel encapsulation.

My understanding of the intent of chisels is to provide a mechanism that encapsulates useful functionality in a specific, but useful way. The lsof chisel gives us file utilization; the echo_fds pretty prints buffer contents; the spectrogram gives us latency visualization. These chisels are all of a class that provide their own direct output. I could imagine a second class of chisels that are effectively super filters. An example would be a chisel that filters out all processes that exist prior to the start of the capture; alternatively an advanced user could write a site/system-specific chisel for colleagues that help them remove extraneous information.

Expected usage would be:

$ sysdig -r original.scap -c filter_preexisting -c filter_db_admins -c lsof

Why do I touch on all this when the topic is display_filter? Chisels control screen output, disregarding anything the sysdig client might want to do. That's what causes this bug; chisels write directly to the screen and the sysdig client has no chance to apply the display_filter. I think cleaning up this behaviour allows us to specifically set expectations for what multiple chisels (and possibly, multiple filters) can do.

Currently, we have three behaviours:

1. chisel -> screen
2. regular filter -> chisel -> screen
3. display filter -> screen

I can imagine more behaviours:
4. regular filter -> display filter -> screen
5. chisel -> display filter -> screen (where this issue started)
6. chisel -> chisel -> screen

A first change would be to implement display_filter as a flag that has it’s own filter argument; this allows behaviour 4.

To allow behaviour 5, you would either want to pass the display filter to the chisel (and ask all chisels to comply), or expose a buffer to the chisel where it can write its results (this buffer is then display_filtered by the sysdig binary). This latter solution allows behaviour 6 (it takes the write-back buffer and passes it as input to chisel2). However, this is tricky, because how do we accomodate chisels like spectrogram that need to write directly to the screen?

Thanks for listening to all this. I want to help implement something, I just want to know the most flexible path forward before making that first step.

[Hefeweizen]

does this make sense as a behaviour:
7. regular filter -> regular filter -> screen

i.e specifying multiple filters on a command line?

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.