Skip to contentSkip to conversation

Add a configure flag to link libc statically

PATCH In review Keno Fischer 2 participants 4 messages Dec 30, 2016 – Jan 16, 2017 netfilter

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 Add a configure flag to link libc statically

The primary concern here is probably that iptables uses functions that in glibc still require the dynamic library at runtime. However, for my usage of iptables, I have never actually run into this situation, and even if I did, I'd rather switch libcs (though I may be in the minority there). Nevertheless, I think it would be useful to have this option available for those wanting a statically linked iptables.

---
 configure.ac         | 10 ++++++++++
 iptables/Makefile.am |  6 ++++++
 2 files changed, 16 insertions(+)
configure.ac +10 -0
index 6ae63f8..a787de9 100644
@@ -67,6 +67,9 @@ AC_ARG_ENABLE([connlabel],
 	AS_HELP_STRING([--disable-connlabel],
 	[Do not build libnetfilter_conntrack]),
 	[enable_connlabel="$enableval"], [enable_connlabel="yes"])
+AC_ARG_ENABLE([static_executables],
+	AS_HELP_STRING([--enable-static-executables], [Statically link executables against libc]),
+	[enable_static_executables="$enableval"], [enable_static_executables="no"])
 
 libiptc_LDFLAGS2="";
 AX_CHECK_LINKER_FLAGS([-Wl,--no-as-needed],
@@ -100,6 +103,7 @@ fi;
 AC_CHECK_SIZEOF([struct ip6_hdr], [], [#include <netinet/ip6.h>])
 
 AM_CONDITIONAL([ENABLE_STATIC], [test "$enable_static" = "yes"])
+AM_CONDITIONAL([ENABLE_STATIC_EXECUTABLES], [test "$enable_static_executables" = "yes"])
 AM_CONDITIONAL([ENABLE_SHARED], [test "$enable_shared" = "yes"])
 AM_CONDITIONAL([ENABLE_IPV4], [test "$enable_ipv4" = "yes"])
 AM_CONDITIONAL([ENABLE_IPV6], [test "$enable_ipv6" = "yes"])
@@ -111,6 +115,11 @@ AM_CONDITIONAL([ENABLE_SYNCONF], [test "$enable_nfsynproxy" = "yes"])
 AM_CONDITIONAL([ENABLE_NFTABLES], [test "$enable_nftables" = "yes"])
 AM_CONDITIONAL([ENABLE_CONNLABEL], [test "$enable_connlabel" = "yes"])
 
+if test "x$enable_static_executables" = "xyes" && test "x$enable_static" != "xyes"; then
+    echo "*** Error: --enable-static-executables without --enable-static. ***"
+    exit 1
+fi
+
 if test "x$enable_bpfc" = "xyes" || test "x$enable_nfsynproxy" = "xyes"; then
 	AC_CHECK_LIB(pcap, pcap_compile,, AC_MSG_ERROR(missing libpcap library required by bpf compiler or nfsynproxy tool))
 fi
@@ -262,6 +271,7 @@ Iptables Configuration:
 
 Build parameters:
   Put plugins into executable (static):	${enable_static}
+  Build static executables (static-executables): ${enable_static_executables}
   Support plugins via dlopen (shared):	${enable_shared}
   Installation prefix (--prefix):	${prefix}
   Xtables extension directory:		${e_xtlibdir}
iptables/Makefile.am +6 -0
index f92cc4f..5c3edec 100644
@@ -12,6 +12,9 @@ xtables_multi_LDADD    = ../extensions/libext.a
 if ENABLE_STATIC
 xtables_multi_CFLAGS  += -DALL_INCLUSIVE
 endif
+if ENABLE_STATIC_EXECUTABLES
+xtables_multi_LDFLAGS  = ${AM_LDFLAGS} -all-static
+endif
 if ENABLE_IPV4
 xtables_multi_SOURCES += iptables-save.c iptables-restore.c \
                          iptables-standalone.c iptables.c
@@ -36,6 +39,9 @@ xtables_compat_multi_LDADD    = ../extensions/libext.a ../extensions/libext_ebt.
 if ENABLE_STATIC
 xtables_compat_multi_CFLAGS  += -DALL_INCLUSIVE
 endif
+if ENABLE_STATIC_EXECUTABLES
+xtables_compat_multi_LDFLAGS  = ${AM_LDFLAGS} -all-static
+endif
 xtables_compat_multi_CFLAGS  += -DENABLE_NFTABLES -DENABLE_IPV4 -DENABLE_IPV6
 xtables_compat_multi_SOURCES += xtables-config-parser.y xtables-config-syntax.l
 xtables_compat_multi_SOURCES += xtables-save.c xtables-restore.c \
Signature · 1 line
2.9.3
#1 lore raw
Quoted 2 lines · Keno Fischer

The primary concern here is probably that iptables uses functions that in glibc still require the dynamic library at runtime.

I think that explains this:

libxt_owner.c:416: warning: Using 'getgrgid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

Quoted 5 lines

However, for my usage of iptables, I have never actually run into this situation, and even if I did, I'd rather switch libcs (though I may be in the minority there). Nevertheless, I think it would be useful to have this option available for those wanting a statically linked iptables.

I'm trying to understand why you need this. Thanks.

#2 lore raw
Quoted 8 lines
Quoted 2 lines

The primary concern here is probably that iptables uses functions that in glibc still require the dynamic library at runtime.

I think that explains this:

libxt_owner.c:416: warning: Using 'getgrgid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

It does, yes. Other C libraries don't have this problem though.

Quoted 7 lines
Quoted 5 lines

However, for my usage of iptables, I have never actually run into this situation, and even if I did, I'd rather switch libcs (though I may be in the minority there). Nevertheless, I think it would be useful to have this option available for those wanting a statically linked iptables.

I'm trying to understand why you need this. Thanks.

I'm running docker in a stripped down security-enhanced context where everything is statically linked. Docker calls out to iptables to set up some firewall rules. So far I have not encountered it needing any of the code paths in iptables that would require the shared libraries from glibc at runtime. I'm also not the only person in this exact situation, e.g.:

https://github.com/vallinux/base/issues/14

#3 lore raw

On Mon, Jan 16, 2017 at 11:39:45AM -0500, Keno Fischer wrote:
[...]

Quoted 8 lines
Quoted 7 lines
Quoted 5 lines

However, for my usage of iptables, I have never actually run into this situation, and even if I did, I'd rather switch libcs (though I may be in the minority there). Nevertheless, I think it would be useful to have this option available for those wanting a statically linked iptables.

I'm trying to understand why you need this. Thanks.

Quoted 8 lines

I'm running docker in a stripped down security-enhanced context where everything is statically linked. Docker calls out to iptables to set up some firewall rules. So far I have not encountered it needing any of the code paths in iptables that would require the shared libraries from glibc at runtime. I'm also not the only person in this exact situation, e.g.:

https://github.com/vallinux/base/issues/14

Thanks for explaining.

It would be good if you can extend iptables building system to catch up with glibc case by rejecting it. Another thing would be to add some small documentation file on the tree that explains how to use this with musl/ulibc.

My only concern about this new option is that people may believe this works out of the box, and so far my impression is that this needs some trickery.

I also wonder if everything is going to work fine with alternative libc libraries, it would be good to run iptables tests (see iptables-test.py) on this binary, you can edit the variable on that script that points to the iptables binary to be tested.

Another alternative if the resulting patch is simple, probably we can allow the override directive so you can easily append -all-static to LDFLAGS at your own risk?

https://www.gnu.org/software/make/manual/make.html#Override-Directive