可能的重复：
为什么共享库可执行？
为什么Linux中.so的文件/lib权限是755而不是644？这看起来很奇怪
根据http://www.gossamer-threads.com/lists/gentoo/user/231943，这似乎是旧的 glibc 的。在我的嵌入式系统 /lib/libc.so.6 上，即使权限为 644，它也能工作。
答案1
我怀疑这可能只是出于历史原因。
BlueBomber 的答案可能在历史上是正确的，但实际上并非如此必要的使共享对象可执行。
在我的 Ubuntu 系统上，它们不是。在 30 个/lib/*.so*和 600 个/usr/lib/*.so*文件中，只有一个具有执行权限，这可能只是一个小故障。
执行权限允许通过其中一个函数执行文件exec*()；共享对象文件包含可执行代码，但它们不是以这种方式执行的。
另一方面，在我可以访问的 CentOS 5.7 系统上，这些文件是可执行文件； SPARC Solaris 9 系统上也是如此。 （尝试关闭其中一些文件的可执行权限以查看它是否会破坏任何内容会很有趣，但我无法这样做。）
（您使用什么 Linux 发行版？）
更新：
这个答案到这个问题显示了实际需要执行位的系统示例 (HP-UX)。 Linux 上的情况似乎并非如此，有些发行版设置了执行位（可能是出于历史惯性），而其他发行版则没有。或者也许某些 Linux 确实需要它。
另一个数据点：在我的 Ubuntu 系统上，我刚刚尝试创建自己的共享对象文件。生成的“libfoo.so”文件是使用执行权限创建的，但如果我手动chmod -x它，使用它的程序仍然可以工作。
无论如何，对*.so文件设置执行权限基本上是无害的（并且当然比对源文件设置执行权限更不烦人）。
更新2：
正如 fwyzard 在评论中指出的那样，某些*.so文件实际上可以执行。例如，在我当前的系统上，执行/lib/x86_64-linux-gnu/libc-2.27.so会打印 GNU C 库的版本信息。 /lib/x86_64-linux-gnu/libpthread-2.27.so行为类似。
答案2
如果我理解你的问题，你会问为什么共享对象文件具有执行权限，那是因为这些是要链接的库文件，并且它们包含的代码是要执行的。
参考：