Should we statically link Tracee?

[yanivagman]

There are several advantages to statically link Tracee:

1. Removes required runtime dependencies - libc, libelf, zlib
2. No more issues with glibc vs musl-libc environments (e.g. alpine vs. ubuntu)
3. Reduces the number of genertated artifacts - no need for two different dockerfiles like we have today

On the other hand:

1. Larger binary size
2. Some features, such as LDAP, require a dynamically linked binary. For this reason, there are several warnings which are emitted during compilation of a statically linked executable, and we should better understand their meaning before we make the decision to statically compile by default:

/usr/bin/ld: /tmp/go-link-409624350/000002.o: in function `mygetgrouplist':
getgrouplist_unix.cgo2.c:(.text+0xa7): warning: Using 'getgrouplist' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: /tmp/go-link-409624350/000001.o: in function `mygetgrgid_r':
cgo_lookup_unix.cgo2.c:(.text+0xdf): warning: Using 'getgrgid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: /tmp/go-link-409624350/000001.o: in function `mygetgrnam_r':
cgo_lookup_unix.cgo2.c:(.text+0x1a1): warning: Using 'getgrnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: /tmp/go-link-409624350/000001.o: in function `mygetpwnam_r':
cgo_lookup_unix.cgo2.c:(.text+0x261): warning: Using 'getpwnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: /tmp/go-link-409624350/000001.o: in function `mygetpwuid_r':
cgo_lookup_unix.cgo2.c:(.text+0x31f): warning: Using 'getpwuid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: /tmp/go-link-409624350/000008.o: in function `_cgo_26061493d47f_C2func_getaddrinfo':
cgo_unix.cgo2.c:(.text+0x48): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

[grantseltzer]

I was unaware of the features that require a dynamically linked binary, so I need to do more research on that.

How does statically compiling remove the need for a second Dockerfile? I'm not familiar with our dockerfile setup.

libc, libelf, and zlib aren't heavy asks as runtime dependencies, but removing them is certainly nice. If we expect tracee-ebpf to typically be run in a container the larger binary size is offset by the removal of those packages. Regardless I don't think binary size is that big of a deal.

I'd say a static binary is simpler than a dynamic one and it's always nice to reduce complexity.

[yanivagman]

How does statically compiling remove the need for a second Dockerfile?

If you'll take a look at the tracee-ebpf dir, you will see that we have two dockerfiles: Dockerfile and Dockerfile.builder.
Dockerfile.builder is used for local builds, where the assumed libc to be used is glibc. It is based on a debian image and compiles a binary that is dynamically linked to glibc.
On the other hand, Dockerfile builds our image to be release and pushed to the docker hub. This image is alpine based, as it is slimmer and has a smaller attack surface. Since it uses alpine, musl-libc is dynamically linked to the binary.

Using a static binary will remove the need to build in two different environments, as no libc needs to be present in runtime for a statically linked binary