I suspect it's probably just for historical reasons.
BlueBomber's answer is probably historically correct, but it's not actually necessary for shared objects to be executable.
On my Ubuntu system, they aren't. Of the 30
/lib/*.so* and 600
/usr/lib/*.so* files, only one has execute permissions, and that's probably just a glitch.
Execute permission permits a file to be executed via one of the
exec*() functions; shared object files contain executable code, but they're not executed in that way.
On the other hand, on a CentOS 5.7 system I have access to, those files are executable; the same is true on a SPARC Solaris 9 system. (It would be interesting to try turning off executable permissions on some of those files to see if it breaks anything, but I'm not able to do so.)
(What Linux distribution are you using?)
This answer to this question shows an example (HP-UX) of a system where the execute bit is actually required. That doesn't appear to be the case on Linux, where some distributions set the execute bit (probably out of historical inertia) and others don't. Or maybe some Linuxes actually require it.
Another data point: On my Ubuntu system, I just tried creating my own shared object file. The generated "libfoo.so" file was created with execute permissions, but if I manually
chmod -x it, the program that uses it still works.
In any case, setting execute permission on
*.so files is Mostly Harmless (and certainly less annoying that, say, setting execute permission on source files).
As fwyzard points out in a comment, some
*.so files can actually be executed. For example, on my current system, executing
/lib/x86_64-linux-gnu/libc-2.27.so prints version information for the GNU C library.
/lib/x86_64-linux-gnu/libpthread-2.27.so behaves similarly.