Optimization #3085
closedSuggest more appropriate location to store eBPF binaries
Description
I noticed that the documentation (https://suricata.readthedocs.io/en/latest/capture-hardware/ebpf-xdp.html#setup-ebpf-filter) suggests /etc/suricata/ebpf
to store compiled eBPF programs. I think that there might be a better location for those. The FHS defines /etc
as the place to store configuration files. By their definition, a "configuration file" is a local file used to control the operation of a program; it must be static and cannot be an executable binary. One might argue that the eBPF programs are not meant to be executable by the host operating system directly, but you get the idea.
I would propose to suggest /usr/share/suricata/ebpf
instead. /usr/share
is meant to contain read-only architecture independent data files, which is the case here (AFAICS the eBPF binary format is independent of the host architecture). For downstream packagers it will make a difference to have a preferred location that most likely complies with their own constraints for installed files -- especially once https://github.com/OISF/suricata/pull/3674 (or one of its descendents) gets merged.
Updated by Victor Julien over 5 years ago
- Status changed from New to Assigned
- Assignee set to Eric Leblond
- Priority changed from Low to Normal
- Target version set to 5.0rc1
I agree with Sascha. Eric can you take this ticket?
Updated by Sascha Steinbiss over 5 years ago
After some research and discussion within the Debian community, it looks like eBPF is apparently endianness-dependent and hence not completely architecture-independent. Hence /usr/lib/$triple/suricata
or /usr/libexec/suricata
would be better.
Updated by Eric Leblond about 5 years ago
Almost implemented by https://github.com/OISF/suricata/pull/4118, as I did miss the last comment.
Updated by Eric Leblond about 5 years ago
- Status changed from Assigned to Closed
Merged with https://github.com/OISF/suricata/pull/4187