自行卸载的 Linux 共享库

Question

我的目标是在位于特定路径的特定进程组中挂钩几个 glibc 函数。有多种方法可以做到这一点（gdb、strace 等）。但我需要在最早阶段自动可靠地制作它，这样我就不会错过任何一个电话。所以我决定使用LD_PRELOAD 方法。而且我需要它在没有任何用户干预的情况下自动完成，因此将LD_PRELOAD 注入环境有点脆弱，可能会被用户覆盖。所以我决定在 /etc/ld.so.preload 中指定我的库 - 这很好用。

在我的库 ctor 代码中，我检查我所在的进程是否是我需要的进程并进行必要的挂钩，否则它是无操作的，库只是一个死重。

__attribute__((constructor)) void my_lib_ctor()
{
  if (is_relevant_process())
  {
    do_the_wiring();
  }
}

该库不导出任何符号，并且默认情况下隐藏其中的所有内容（-fvisibility=hidden 编译器标志），因此任何进程对我的库没有任何真正的依赖关系。因此，如果注入到无关的进程中，它可以安全地卸载。

更新过程需要卸载 - 如果要更新库，则不应将其加载到长时间运行的进程中 - 否则它们将在库替换时崩溃（这是预期的）。感兴趣的过程是短暂的并且是由用户启动的，因此对它们的影响可以忽略不计。

问题是 - 我不知道如何安全卸载它。我在考虑dlclose，但是从库本身调用它会导致它从调用返回到已经卸载的库代码。

如果有其他方法可以自动且可靠地在早期（在应用程序的main() 执行之前）挂钩 glibc 调用而不触及感兴趣的应用程序本身，我会很高兴如果你让我知道它们（操作系统配置的轻微修改，例如预加载，是可以的）。谢谢！

Answer 1

我认为你有一些误解，你所要求的只是没有意义：

在我的库 ctor 代码中，我检查我所在的进程是否是我需要的进程并进行必要的挂钩，否则它是无操作的，库只是一个死重。

还有卸载它的工作，而不是让它无所事事，它更多重量。

更新过程需要卸载 - 如果要更新库，则不应将其加载到长时间运行的进程中 - 否则它们将在库替换时崩溃（这是预期的）。

只有当您错误地覆盖库文件而不是替换文件时，才会发生这种情况。后者可以通过将临时文件安装到同一目录并以旧文件为目标执行rename 函数（等效于mv 命令）来执行。

如果还有其他方法可以在早期自动可靠地挂钩 glibc 调用

您对“可靠”的关注听起来非常接近想要使用这种机制以潜在的恶意应用程序无法绕过的方式实施策略/访问控制。这在图书馆级别根本不可能。您需要在某种真正的沙箱中运行它们才能实现这一点（例如，通过将文件替换为在适当的沙箱中调用它们的包装脚本）。