v0.5.4 — What this machine can and cannot do

Roadmap item 0.5.4.

$ flowlightd check
ok  kernel                 6.8.0-45-generic — new enough for the probes
?   permission to load     not running as root. The daemon needs root or CAP_BPF to load anything; whether
                           this machine would allow it cannot be answered from here.
?   tracefs                /sys/kernel/tracing is mounted, and the file describing the tracepoint is
                           readable only by root — so whether its layout can be read cannot be answered
                           from here.
ok  refusing connections   cgroup v2 at /sys/fs/cgroup
ok  TLS libraries          /usr/lib/x86_64-linux-gnu/libssl.so.3 (openssl), …
ok  SELinux                SELinux is not enforcing anything here
ok  BPF in this kernel     present

Every other way of finding this out is a failure: a probe that will not attach, a rule that never bites, an empty screen. This asks the same questions in advance and says what each answer costs — the difference between "it does not work here" and "it does not work here because".

• Read-only. It loads nothing, attaches nothing, writes nothing, and does not even open the database: a report about a machine must not leave a file on it.
• Runnable by anybody, because the person reading it when something is wrong is not always the person with root.
• Essential and inessential are separated. No cgroup v2 hierarchy means watching works and refusing does not, which is a line in the report rather than a failure. A kernel older than 4.18, no readable tracepoint layout, or a kernel built without CONFIG_BPF_SYSCALL are failures, and the command exits non-zero so a script can ask.

The fix that writing it demanded

CGROUP_ROOT was hard-coded to /sys/fs/cgroup. That is right on everything current and wrong on a hybrid hierarchy — RHEL 8's default, and Ubuntu's before 21.10 — where the cgroup v2 tree is one directory down at /sys/fs/cgroup/unified. Blocking there failed with a path in the message and no explanation of it.

The tree is now found rather than assumed: unified, hybrid, or neither. The third says plainly that connections cannot be refused, that watching is unaffected, and what to boot with to change it.

Being root is not the same as something being absent

The first version of this told a person running it that their machine could not be watched — because the file describing the tracepoint is readable only by root, and the report read "permission denied" as "no tracefs". Those two are a sudo and a mount command.

Asking whether the directory exists is a question anybody may ask, so that is what is asked; the layout file stays root's alone. A person gets unknown, with the reason, and no verdict about the machine on the strength of who is asking.

A crate whose functions take the root they read

flowlight-platform. hierarchy("/sys/fs/cgroup") on a machine, hierarchy(a_temporary_directory) in a test — because the only way to have a test for the hybrid hierarchy on a machine that does not have one is to write the directory out.

Seven tests do that: four release strings as four distributions actually write them (6.8.0-45-generic, 5.14.0-427.el9.x86_64, 6.6.9-arch1-1, 4.18.0-513.el8.x86_64), the 4.18 boundary from both sides, and all three cgroup layouts. It builds and its tests run anywhere, including the machines the rest of this cannot be compiled on.

Verified

Seven unit tests in the new crate. The smoke test asserts that as root every essential finding is present and positive, that no finding says nothing — a report of bare yeses is one nobody can act on — that refusing connections is reported as not essential, and that as a person the two things that cannot be answered come back unknown while the verdict stays ready.