可能的重复：
为什么共享库是可执行的？
为什么Linux 中的.so文件/lib具有 755 权限而不是 644 权限？这看起来很奇怪
根据http://www.gossamer-threads.com/lists/gentoo/user/231943，它似乎适用于旧 glibc。在我的嵌入式系统 /lib/libc.so.6 上，即使权限是 644，它也能工作。
我怀疑这可能只是出于历史原因。
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行为类似。