[Question] libseccomp runtime dependency

[sipasing]

Noob question, I see "Static Linking notices" on the releases page stating that libseccomp is a build-time dependency of runc, meaning that libseccomp-devel package should be installed on the system during runc build.

But what about runtime dependency ? I notice in Openela repo, runc spec having both a buildtime (BuildRequires tag) and a runtime (Requires tag) dependency on libseccomp. Can someone point me to the docs or explain why a runtime dependency for libseccomp is present.

Also Ques2) diving into build time dependency, how does this static linking take place ? Is there a library in libseccomp-devel package that runc is supposed to link against ?

[cyphar]

(This probably would've been better left as a discussion thread, but I'll answer here anyway.)

The binaries we build and ship on the releases page are statically linked, in order to make sure they work on any Linux system. There is no runtime dependency on libseccomp for those binaries because libseccomp is already embedded inside the binary.

However, distributions usually prefer shared linking (aka dynamic linking) where the binary has a reference to libseccomp.so that the link loader will load when the binary is executed. They usually prefer this because it (in theory) allows you to update the shared library with patches without having to rebuild every dependency, and improves memory usage and disk space for very commonly used libraries. In that case, you need to have libseccomp.so installed at runtime, and this is a general property of shared libraries. You can see the list of shared libraries a dynamically linked binary depends on using ldd:

ldd examples

% ldd /usr/bin/runc
        linux-vdso.so.1 (0x00007faf37e3a000)
        libseccomp.so.2 => /lib64/libseccomp.so.2 (0x00007faf37dfd000)
        libc.so.6 => /lib64/libc.so.6 (0x00007faf36e00000)
        /lib64/ld-linux-x86-64.so.2 (0x00007faf37e3c000)
% ldd /opt/google/chrome/chrome
        linux-vdso.so.1 (0x00007f850b226000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f850b204000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f850b1ff000)
        libgobject-2.0.so.0 => /lib64/libgobject-2.0.so.0 (0x00007f850b19d000)
        libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00007f84fbeb2000)
        libnss3.so => /lib64/libnss3.so (0x00007f84fbd71000)
        libnssutil3.so => /lib64/libnssutil3.so (0x00007f850b166000)
        libsmime3.so => /lib64/libsmime3.so (0x00007f850b139000)
        libnspr4.so => /lib64/libnspr4.so (0x00007f850b0f7000)
        libdbus-1.so.3 => /lib64/libdbus-1.so.3 (0x00007f84fbd1e000)
        libatk-1.0.so.0 => /lib64/libatk-1.0.so.0 (0x00007f850b0cc000)
        libatk-bridge-2.0.so.0 => /lib64/libatk-bridge-2.0.so.0 (0x00007f84fbcdf000)
        libcups.so.2 => /lib64/libcups.so.2 (0x00007f84fbc28000)
        libgio-2.0.so.0 => /lib64/libgio-2.0.so.0 (0x00007f84fba35000)
        libdrm.so.2 => /lib64/libdrm.so.2 (0x00007f84fba1d000)
        libexpat.so.1 => /lib64/libexpat.so.1 (0x00007f84fb9f1000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f84fb906000)
        libX11.so.6 => /lib64/libX11.so.6 (0x00007f84fb7bf000)
        libXcomposite.so.1 => /lib64/libXcomposite.so.1 (0x00007f84fb7ba000)
        libXdamage.so.1 => /lib64/libXdamage.so.1 (0x00007f84fb7b5000)
        libXext.so.6 => /lib64/libXext.so.6 (0x00007f84fb7a0000)
        libXfixes.so.3 => /lib64/libXfixes.so.3 (0x00007f84fb798000)
        libXrandr.so.2 => /lib64/libXrandr.so.2 (0x00007f84fb78b000)
        libgbm.so.1 => /lib64/libgbm.so.1 (0x00007f84fb767000)
        libxcb.so.1 => /lib64/libxcb.so.1 (0x00007f84fb73b000)
        libxkbcommon.so.0 => /lib64/libxkbcommon.so.0 (0x00007f84fb6f1000)
        libpango-1.0.so.0 => /lib64/libpango-1.0.so.0 (0x00007f84fb686000)
        libcairo.so.2 => /lib64/libcairo.so.2 (0x00007f84fb548000)
        libudev.so.1 => /lib64/libudev.so.1 (0x00007f84fb501000)
        libasound.so.2 => /lib64/libasound.so.2 (0x00007f84fb3f4000)
        libatspi.so.0 => /lib64/libatspi.so.0 (0x00007f84fb3b8000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f84fb38a000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f84fb000000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f850b228000)
        libffi.so.8 => /lib64/libffi.so.8 (0x00007f84fb37f000)
        libpcre2-8.so.0 => /lib64/libpcre2-8.so.0 (0x00007f84fb2d2000)
        libplc4.so => /lib64/libplc4.so (0x00007f84fb2cb000)
        libplds4.so => /lib64/libplds4.so (0x00007f84fb2c6000)
        libsystemd.so.0 => /lib64/libsystemd.so.0 (0x00007f84faf16000)
        libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f84fb272000)
        libavahi-common.so.3 => /lib64/libavahi-common.so.3 (0x00007f84fb261000)
        libavahi-client.so.3 => /lib64/libavahi-client.so.3 (0x00007f84fb24e000)
        libgnutls.so.30 => /lib64/libgnutls.so.30 (0x00007f84fac00000)
        libz.so.1 => /usr/lib64/zlib-ng-compat/libz.so.1 (0x00007f84fb22c000)
        libgmodule-2.0.so.0 => /lib64/libgmodule-2.0.so.0 (0x00007f84fb225000)
        libmount.so.1 => /lib64/libmount.so.1 (0x00007f84faec9000)
        libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f84fae9a000)
        libXrender.so.1 => /lib64/libXrender.so.1 (0x00007f84fb216000)
        libgallium-24.2.7.so => /lib64/libgallium-24.2.7.so (0x00007f84f8400000)
        libwayland-server.so.0 => /lib64/libwayland-server.so.0 (0x00007f84fae84000)
        libxcb-randr.so.0 => /lib64/libxcb-randr.so.0 (0x00007f84fae72000)
        libXau.so.6 => /lib64/libXau.so.6 (0x00007f84fae6d000)
        libfribidi.so.0 => /lib64/libfribidi.so.0 (0x00007f84fae4d000)
        libthai.so.0 => /lib64/libthai.so.0 (0x00007f84fae41000)
        libharfbuzz.so.0 => /lib64/libharfbuzz.so.0 (0x00007f84f82e1000)
        libpng16.so.16 => /lib64/glibc-hwcaps/x86-64-v3/libpng16.so.16.44.0 (0x00007f84fabb2000)
        libfontconfig.so.1 => /lib64/libfontconfig.so.1 (0x00007f84fab63000)
        libfreetype.so.6 => /lib64/libfreetype.so.6 (0x00007f84f8223000)
        libxcb-render.so.0 => /lib64/libxcb-render.so.0 (0x00007f84fae32000)
        libxcb-shm.so.0 => /lib64/libxcb-shm.so.0 (0x00007f84fae2d000)
        libpixman-1.so.0 => /lib64/libpixman-1.so.0 (0x00007f84f81ab000)
        libcap.so.2 => /lib64/libcap.so.2 (0x00007f84fae21000)
        libXi.so.6 => /lib64/libXi.so.6 (0x00007f84f8197000)
        libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f84f80c8000)
        libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f84f80b0000)
        libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f84fab5d000)
        libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f84f80a1000)
        libjitterentropy.so.3 => /lib64/libjitterentropy.so.3 (0x00007f84f8097000)
        libp11-kit.so.0 => /lib64/libp11-kit.so.0 (0x00007f84f7f0f000)
        libidn2.so.0 => /lib64/libidn2.so.0 (0x00007f84f7eed000)
        libunistring.so.5 => /lib64/libunistring.so.5 (0x00007f84f7d04000)
        libtasn1.so.6 => /lib64/libtasn1.so.6 (0x00007f84f7ced000)
        libhogweed.so.6 => /lib64/glibc-hwcaps/x86-64-v3/libhogweed.so.6.9 (0x00007f84f7ca2000)
        libnettle.so.8 => /lib64/glibc-hwcaps/x86-64-v3/libnettle.so.8.9 (0x00007f84f7c49000)
        libgmp.so.10 => /lib64/libgmp.so.10 (0x00007f84f7ba2000)
        libblkid.so.1 => /lib64/libblkid.so.1 (0x00007f84f7b66000)
        libglapi.so.0 => /lib64/libglapi.so.0 (0x00007f84f7b32000)
        libLLVM.so.19.1 => /lib64/libLLVM.so.19.1 (0x00007f84f0200000)
        libX11-xcb.so.1 => /lib64/libX11-xcb.so.1 (0x00007f84f7b2d000)
        libxcb-dri3.so.0 => /lib64/libxcb-dri3.so.0 (0x00007f84f7b26000)
        libxcb-present.so.0 => /lib64/libxcb-present.so.0 (0x00007f84f7b20000)
        libxcb-xfixes.so.0 => /lib64/libxcb-xfixes.so.0 (0x00007f84f7b16000)
        libxcb-sync.so.1 => /lib64/libxcb-sync.so.1 (0x00007f84f7b0d000)
        libxshmfence.so.1 => /lib64/libxshmfence.so.1 (0x00007f84f7b08000)
        libdrm_radeon.so.1 => /lib64/libdrm_radeon.so.1 (0x00007f84f7af8000)
        libelf.so.1 => /lib64/libelf.so.1 (0x00007f84f7adc000)
        libdrm_amdgpu.so.1 => /lib64/libdrm_amdgpu.so.1 (0x00007f84f7acf000)
        libdrm_intel.so.1 => /lib64/libdrm_intel.so.1 (0x00007f84f7aa9000)
        libxcb-dri2.so.0 => /lib64/libxcb-dri2.so.0 (0x00007f84f7aa2000)
        libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f84efe00000)
        libdatrie.so.1 => /lib64/libdatrie.so.1 (0x00007f84f7a97000)
        libgraphite2.so.3 => /lib64/libgraphite2.so.3 (0x00007f84f7a76000)
        libbz2.so.1 => /lib64/glibc-hwcaps/x86-64-v3/libbz2.so.1.0.6 (0x00007f84f7a5d000)
        libbrotlidec.so.1 => /lib64/glibc-hwcaps/x86-64-v3/libbrotlidec.so.1.1.0 (0x00007f84f7a4f000)
        libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f84f7a48000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f84f7a34000)
        libcrypto.so.3 => /lib64/glibc-hwcaps/x86-64-v3/libcrypto.so.3.2.3 (0x00007f84ef800000)
        libeconf.so.0 => /lib64/libeconf.so.0 (0x00007f84f7a25000)
        libedit.so.0 => /lib64/libedit.so.0 (0x00007f84f79e9000)
        libzstd.so.1 => /lib64/glibc-hwcaps/x86-64-v3/libzstd.so.1.5.6 (0x00007f84f014b000)
        libxml2.so.2 => /lib64/libxml2.so.2 (0x00007f84ef68d000)
        libpciaccess.so.0 => /lib64/libpciaccess.so.0 (0x00007f84f79db000)
        libbrotlicommon.so.1 => /lib64/glibc-hwcaps/x86-64-v3/libbrotlicommon.so.1.1.0 (0x00007f84f79b8000)
        libtinfo.so.6 => /lib64/libtinfo.so.6 (0x00007f84f010f000)
        liblzma.so.5 => /lib64/glibc-hwcaps/x86-64-v3/liblzma.so.5.6.3 (0x00007f84f00d4000)

It is a little odd that they need to put an explicit Requires for libseccomp though -- rpm will automatically find all dynamic library dependencies and generate Requires automatically. This is how the openSUSE runc specfile works. I guess the specfile comes from RHEL, where they have a different policy on defining Requires.

How does this static linking take place ? Is there a library in libseccomp-devel package that runc is supposed to link against ?

Dynamic linking is done against libseccomp.so, static linking is done against libseccomp.a. Your distribution might not provide libseccomp.a (for instance, openSUSE only ships the .so for libseccomp).

For runc in particular, we build our own copy of libseccomp (see scripts/release_build.sh) and then do some hacks (see the static-bin rule in Makefile -- it's mainly -extldflags -static and -tags "netgo osusergo") to force Go to produce a static binary. Except in very specific circumstances, normally Go produces dynamically linked binaries.

[sipasing]

(This probably would've been better left as a discussion thread, but I'll answer here anyway.)

Noted for next time.

[sipasing]

Hmm. I was talking about compiled (and dynamically linked) runc binaries. But thanks for explaining both cases ( compiled and to-be-compiled).

Before this discussion, I used to think that compiled runc , at runtime, is dependent to a specific libseccomp version since I always saw the "Assets section" on the releases page here as a benchmark that distros would follow. But like u said, distributions tend to avoid using patch-version-level requirements due to specfile churn. Which kind of makes sense.

So the fact that the runc v1.1.3 built using this spec file, https://github.com/openela-main/runc/blob/60f3a7882c23095c06aab516e5567fd89efb7f1f/SPECS/runc.spec#L39, could link to shared libseccomp library available from libseccomp-2.5.1 or 2.5.2 or 2.5.3 or 2.5.4 or 2.5.5 depending on whats installed on the system at runtime (since anything >2.5 works) and even though the runc packaged in the Releases/Assets section uses libseccomp-2.5.5, both these scenarios (the open ELA spec and/or upstream runc Assets binary) would have no runtime behavioral difference with respect to runc.

[cyphar]

Yup, that is correct, unless libseccomp has some backwards-compatibility breaking bug but that would be a problem with libseccomp not runc. In general, you should try to use the latest version of libseccomp you can because otherwise newer system call names won't be understood by libseccomp and you won't be able to write allow rules for them.

[akhilerm]

For compiling runc, we have the same minimum version requirement as the libseccomp-golang package we use. At the moment, v0.10.0 has a minimum version requirement of libseccomp 2.3.1.

Does this mean that we can compile / link latest version of runc against a different version of seccomp (2.4.0 in my case) and expect no breakages?

I am trying to compile runc on photon3, which has libc 2.28 and libseccomp 2.4.0. Since the version was mentioned as 2.5, was confused whether runc depends on any specific features from that version. But AFAIU now, any version > 2.3.1 should work with runc while both compiling and running on the same version of libraries

[cyphar]

@akhilerm We don't test older versions in our upstream CI, so I can't give a definitive answer other than "if it builds I would expect it to work, and if there is an issue it's probably an issue in libseccomp-golang but we would need to debug it to figure that out".

[akhilerm]

Got it . Thank you