Project

General

Profile

Optimization #3085

Suggest more appropriate location to store eBPF binaries

Added by Sascha Steinbiss 3 months ago. Updated about 1 month ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
Effort:
Difficulty:
Label:

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.

History

#1

Updated by Victor Julien 3 months 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?

#2

Updated by Sascha Steinbiss 3 months 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.

#3

Updated by Eric Leblond about 2 months ago

Almost implemented by https://github.com/OISF/suricata/pull/4118, as I did miss the last comment.

#4

Updated by Eric Leblond about 1 month ago

  • Status changed from Assigned to Closed

Also available in: Atom PDF