Feature #2931

Perform privdrop without libcap-ng support

Added by Emmanuel Roullit 5 months ago. Updated 5 months ago.

Target version:


Some platforms might not have libcap-ng support which disables the "run-as" configuration option and leaves the user with no other options but to run suricata with elevated privileges.

We created a changeset which allows to drop privileges despite the lack of libcap-ng support.

It lets the main thread perform initialization with the needed elevated privileges and drops them, by using setresuid(2) and setresgid(2), right before the SuricataMainLoop() is entered.

There is a caveat, which has been documented in the changeset, RUNMODE_AFP_DEV requires elevated privileges to allow the packet acquisition threads to reopen an AF_PACKET socket.
To guard against this, suricata will not start and inform the user libcap-ng support is required when the following requirements are met:
- libcap-ng support is disabled
- uid or gid change requested
- RUNMODE_AFP_DEV main run mode detected

Does other runmodes such as RUNMODE_PFRING and RUNMODE_NAPATECH would require similar guard as well?

Related issues

Related to Feature #276: Libcap support for dropping privilegesNewActions



Updated by Victor Julien 5 months ago

  • Related to Feature #276: Libcap support for dropping privileges added

Updated by Victor Julien 5 months ago

I think a cleaner option would be to disable the whole reconnect/reopen feature in af-packet when we know it can't work. We can determine this at start up, so we might have a message at initialization of af-packet.


Updated by Eric Leblond 5 months ago

Agree with Victor on reconnect. It is really unlikely it happens on standard ethernet interface so we could disable it in this case.

But question, is there Linux distribution without libcap-ng available ?


Updated by Victor Julien 5 months ago

Right now libcap-ng is not mandatory on Linux, so we need to think about how to handle the case where its not available. Perhaps we can simply make it mandatory for Linux.


Updated by Emmanuel Roullit 5 months ago

I am not aware of a specific Linux distro having this situation. So test this case on my machine, I forced LIBCAP_NG to "no" like this:

diff --git a/ b/
index 41e1b13..287fa43 100644
--- a/
+++ b/
@@ -1711,7 +1711,7 @@
         LDFLAGS="${LDFLAGS}  -L${with_libcap_ng_libraries}" 

-    AC_CHECK_HEADER(cap-ng.h,,LIBCAP_NG="no")
+    AC_CHECK_HEADER(cap-ng.h,LIBCAP_NG="no",LIBCAP_NG="no")
     if test "$LIBCAP_NG" != "no"; then


Updated by Emmanuel Roullit 5 months ago

A v2 Pull request has been published:

Also available in: Atom PDF