Repository navigation
Document the required glibc version for wide compatibilty #70
Description
Activity
Thanks! FYI, I use the following Dockerfile to ensure that I have the same glibc as the one in Falco:
# Use the same base image as falco to ensure compatibility with glibc version FROM golang:buster as builder # Cache go modules so they won't be downloaded at each build COPY go.mod go.sum /src/ RUN cd /src && go mod download COPY ./ /src RUN cd /src && make -C falco-plugin # Use the following command to get the built files: # DOCKER_BUILDKIT=1 docker build -f falco-plugin/Dockerfile --output=falco-plugin/ . FROM scratch AS deploy-source COPY --from=builder /src/falco-plugin/*.so /
Reacted by Leonardo GrassoBtw, to build and publish our plugins, we currently use this 👇
https://github.com/falcosecurity/test-infra/blob/master/images/build-plugins/Dockerfile#L6Issues go stale after 90d of inactivity.
Mark the issue as fresh with
/remove-lifecycle stale.Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with
/close.Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale
/remove-lifecycle stale
Issues go stale after 90d of inactivity.
Mark the issue as fresh with
/remove-lifecycle stale.Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with
/close.Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale
/remove-lifecycle stale
@falcosecurity/falco-maintainers Shall we do the same for Falco?
Issues go stale after 90d of inactivity.
Mark the issue as fresh with
/remove-lifecycle stale.Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with
/close.Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale
/remove-lifecycle stal
65 remaining items
Issues go stale after 90d of inactivity.
Mark the issue as fresh with
/remove-lifecycle stale.Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with
/close.Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale
/remove-lifecycle stale
Issues go stale after 90d of inactivity.
Mark the issue as fresh with
/remove-lifecycle stale.Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with
/close.Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with
/remove-lifecycle rotten.Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with
/close.Provide feedback via https://github.com/falcosecurity/community.
/lifecycle rotten
/remove-lifecycle rotten
Some data on the floor question, from a lab run of Falco 0.44.1 across five legacy distros (CentOS 7, Ubuntu 18.04, Ubuntu 20.04, Rocky 8, Debian 11). Full write-up in #1500.
Short version: there are two separate failures below glibc 2.34, and I think conflating them is part of why this number has been hard to pin down.
1. A missing link flag — not a floor
On glibc 2.28–2.33 the packaged
libcontainer.sofails todlopenwithundefined symbol: __res_search.The Go worker's cgo resolver calls
res_search, butgo-worker.cmakeadds-lresolvonly inside theif(APPLE)branch — there is no Linux equivalent. The shipped.sotherefore declares no dependency on the library that provides the symbol:$ readelf -d libcontainer.so | grep NEEDED (NEEDED) Shared library: [libc.so.6] (NEEDED) Shared library: [ld-linux-x86-64.so.2]glibc 2.34 merged libresolv into libc, which hides this on modern hosts. Below 2.34 the symbol lives only in
libresolv.so.2, which nothing loads. On a stock Debian 11 install,LD_PRELOAD=/lib/x86_64-linux-gnu/libresolv.so.2 falcostarts cleanly — same binary, same config, one variable.This hits Debian 11, Ubuntu 20.04, and the whole RHEL/Rocky/Alma 8 line. Because plugin loading precedes engine selection, it kills modern_ebpf, legacy ebpf and kmod identically — which is why it presents as kernel incompatibility on a matrix. Fix in #1501 (two lines; link order is load-bearing, note in the PR).
@FedeDP — re your 2025-07-21 comment: the go-worker cgo layer is involved as you suspected, but the mechanism here is a missing
DT_NEEDEDrather than a raised symbol-version requirement.2. The real floor is 2.28 — and it rests on one symbol
Separately, on Ubuntu 18.04 (glibc 2.27) the plugin fails differently:
version 'GLIBC_2.28' not found. That is the plugin's build baseline and no link flag lowers it.Symbol-version histogram of the plugin (x86_64):
202 GLIBC_2.2.5 6 GLIBC_2.3 2 GLIBC_2.3.2 2 GLIBC_2.4 1 GLIBC_2.6 2 GLIBC_2.14 1 GLIBC_2.28 <- fcntl64The entire 2.28 requirement rests on a single symbol,
fcntl64@GLIBC_2.28, pulled in via the Go toolchain. Everything else is 2.14 or older.@leogr — re your TODO from 2025-07-02: 2.28 is correct to document as today's requirement. But the blocker is narrower than it looks: if
fcntl64were avoided, or go-worker built on a base older than 2.28, the floor would drop toward 2.14. I have not tested that, so please treat it as a lead rather than a result.Where the floor actually bites
Distro glibc Falco 0.44.1 today With #1501 Ubuntu 24.04 2.39 works works Debian 11 2.31 plugin crash-loop works Ubuntu 20.04 2.31 plugin crash-loop works Rocky/RHEL/Alma 8 2.28 plugin crash-loop works Ubuntu 18.04 2.27 installs, plugin won't load still won't load Amazon Linux 2 2.26 installs, plugin won't load still won't load CentOS 7 2.17 package refuses to install n/a — 0.40.0 is the EL7 cutoff One packaging inconsistency worth capturing while this gets documented: on EL7 the RPM refuses cleanly on
Requires: libc.so.6(GLIBC_2.28). On Ubuntu 18.04 and Amazon Linux 2 the package installs successfully and then the default-enabled plugin fails to load. A clean refusal is a better outcome than an install that doesn't work.Verification after the patch
- Debian 11 (2.31) — was crash-looping under systemd; now runs stock, default rules load, detections fire.
- Ubuntu 24.04 (2.39) — already worked; identical behaviour after, no regression.
- aarch64 — builds clean, same
NEEDEDentry. The newly linked symbol is__res_search@GLIBC_2.17(aarch64's baseline stamp;@GLIBC_2.2.5on x86_64), so the fix adds no version requirement. - macOS / Windows — untouched; the
APPLEbranch is unchanged andWORKER_DEPis never set on Windows.
The patch changes no plugin code — it only declares a dependency the plugin always had.
What to document
Plugins authors must build their plugins using the same glibs version we use in Falco. We have to document that.
/cc @jasondellaluce