这几乎但不完全是“https://unix.stackexchange.com/questions/61646/why-are-so-files-executable”的重复。
我注意到，在基于 Red Hat 的系统上，共享库具有执行权限，但在 Debian 上却没有。
从逻辑上讲，分片库本身不可执行，除非它们是经过设计的（通过巧妙的链接）。但是，它们包含的代码会被执行。所以它有点灰色地带。
链接的问题表明它是出于历史原因，也是某些类 Unix 操作系统（如 HP-UX）的要求。
我想更深入地了解 Debian 和 Red Hat 不同的原因。
哪个系统发生了变化，为什么？
BSD 的情况如何？
是否有任何可能的安全考虑？
更新：2017 年 10 月 26 日
以下是红帽关于这个主题的说法（重点是我的）：
在库上设置可执行位除了可以从 shell 执行之外没有任何效果。 Linux 中的共享库采用一种称为 ELF 的格式，它代表可执行和可链接格式。这是可执行文件和共享库的格式，因此这就是库被标记为可执行位的原因。值得注意的是，GCC 默认创建带有可执行位设置的共享库。
删除可执行位不会有任何副作用（除了无法运行某些库来显示其信息，例如 libc），因为动态加载器不关心库的权限：它而是映射库的部分内容到部分内存，而那些需要执行的则映射到先前标记为 PROT_EXEC 的内存区域。
正如所指出的，Debian 政策将库安装为不可执行。我认为 gcc （或者更确切地说 ld ）是独立于平台的，因为谨慎而使库默认可执行？
这里有一篇有趣的文章：https://www.technovelty.org/linux/shared-libraries-and-execute-permissions.html
也可以看看https://stackoverflow.com/questions/6299395/gcc-generates-shared-object-with-execute-permissions
答案1
Debian 在 1997 年的策略版本 2.2 中对此进行了更改（请参阅第7129章，尽管这根本没有提供太多细节，而且我还没有找到任何其他讨论）；原因已给出因此在当前版本的政策中：
共享库不应安装为可执行文件，因为动态链接器不需要此文件，并且尝试执行共享库通常会导致核心转储。
所以这实际上是关于管理期望和最小惊喜原则：如果执行它没有用，就不要将其标记为可执行。在 Debian 及其衍生版本上，唯一应该可执行的库是那些在执行时执行一些合理操作的库（例如 C 库、libpthread当然还有动态链接器）。
至少在 FreeBSD 和 OpenBSD 上，操作系统中的共享库是不可执行的。在 OpenBSD 上，对于/usr/local.在 FreeBSD 上，/usr/local端口和包中的共享库通常是可执行的。 （谢谢杰德BP为了BSD 相关信息.)
在Linux上，我认为没有任何特殊的安全考虑（至少在基本的Linux系统上没有），因为运行库不需要设置其可执行位（您可以使用动态链接器运行它） 。