为什么共享库应该或不应该是可执行的（例如 Red Hat 与 Debian）？

Question

这几乎但不完全是“为什么 .so 文件可执行？ ”的重复。

我注意到在基于 Red Hat 的系统上共享库具有执行权限，但在 Debian 上它们没有。

从逻辑上讲，分片库本身是不可执行的，除非它们是设计使然（通过巧妙的链接）。但是，它们包含的代码会被执行。所以它有点灰色地带。

有一个有趣的文章

链接的问题表明它出于历史原因，而且它是某些类 Unix 操作系统（如 HP-UX）的要求。

我想更深入地了解 Debian 和 Red Hat 在这里不同的原因。

哪个系统发生了变化，为什么？

BSD 上的情况如何？

是否有任何可能的安全考虑？

---

更新：2017 年 10 月 26 日

以下是 Red Hat 对这个主题的看法（重点是我的）：

除了可以从 shell 执行之外，在库上设置可执行位不会产生任何影响。Linux 中的共享库采用一种称为 ELF 的格式，它代表 Executable and Linkable Format。这是可执行文件和共享库的格式，因此这就是库被标记为可执行位的原因。值得注意的是，GCC 创建了默认设置了可执行位的共享库。

删除可执行位没有任何副作用（除了不能运行某些库来显示它们的信息，例如 libc），因为动态加载器不关心库的权限：它而是映射库的一部分到内存的一部分，那些需要执行的被映射到先前标记为 PROT_EXEC 的内存区域。

正如所指出的那样，Debian 政策将库安装为不可执行的。我认为 gcc（或者更确切地说 ld）是平台无关的错误，通过使库默认可以执行来谨慎行事？

这里有一篇有趣的文章：https : //www.technovelty.org/linux/shared-libraries-and-execute-permissions.html

另见/sf/ask/440957681/

Answer 1

Debian 在 1997 年的 Policy version 2.2 中对此进行了更改（请参阅#7129，尽管这根本没有提供太多细节，我还没有找到任何其他讨论）；原因在当前版本的 Policy 中给出：

共享库不应该被安装为可执行的，因为动态链接器不需要这个并且尝试执行共享库通常会导致核心转储。

所以这真的是关于管理期望，以及最小惊喜的原则：如果执行它没有用，不要将它标记为可执行。在 Debian 及其衍生产品上，唯一应该是可执行的库是那些在执行时做一些有意义的事情的库（例如 C 库，libpthread当然还有动态链接器）。

至少在 FreeBSD 和 OpenBSD 上，操作系统的共享库是不可执行的。在 OpenBSD 上，这对于/usr/local. 在 FreeBSD 上，/usr/local来自端口和包的共享库通常是可执行的。（感谢JdeBP提供BSD 相关信息。）

在 Linux 上，我认为没有任何特殊的安全考虑（至少在基本的 Linux 系统上没有），因为运行库不需要设置其可执行位（您可以使用动态链接器运行它） .