linux - 静态链接程序在 gcc 4.7 中正常，在 gcc 4.8 中失败。在运行时使用 dlopen

Question

我有一个程序在运行时使用如下代码将用户名解析为 uid:

pw_user = getpwnam(username);

这个特定的调用在运行时需要系统的 libc，即使程序是静态链接的。

因为我不信任运行时环境，所以这个程序是静态链接的，并且这个调用是在用户 nobody 下的专用分支中运行的。

当构建在带有 GCC 4.7.2 的 Debian Wheezy box 上时，它在任何运行时环境中都可以正常工作。相反，当在带有 GCC 4.8.2 的 Ubuntu Trusty box 上构建时，构建工作正常，但用户名解析总是失败。

这是构建于:

gcc -Wall -W -Werror -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat \
    -Werror=format-security -static  main.c -o main

此处的大部分参数来自 dpkg-buildflags --get CFLAGS，它在两种环境下产生相同的输出。

我怀疑 GCC 4.8 中可能存在影响静态链接二进制文件中的 ldopen 的变化，但我没有从 GCC 的变更日志 (https://gcc.gnu.org/gcc-4.8/changes.html) 中注意到任何类似的内容。

另一个可能的嫌疑人可能是 glibc。 wheezy下的版本是glibc-2.13-1，Ubuntu下的版本是glibc-2.19-1。

Answer 1

This specific call requires system's libc at runtime, even when the program is statically linked.

这是正确的，但这不是全部的故事。您应该收到一条警告，指出在运行时安装的 libc.so 版本必须与您在链接时使用的相同。

换句话说，通过静态链接您的二进制文件，您使您的二进制文件极度不可移植。它仅在具有glibc-2.13(或glibc-2.19)的系统上工作，无处在其他系统上。

When built on a Debian Wheezy box with GCC 4.7.2, this works just fine in any runtime environment.

如果是这样，那只是偶然。

when build on an Ubuntu Trusty box with GCC with GCC 4.8.2 the build works fine but the user name resolve always fails.

它应该不会在同一台机器上失败(即带有 glibc-2.19 的机器)，它可能在任何其他机器上失败。这是设计好的。

As I can't trust the run time environment, this program is statically linked and this call is ran inside a dedicated fork under user nobody.

您还必须在 chroot 中运行此程序，并使用与您的构建环境相匹配的 libc.so。预计其他任何方法都不起作用。