2 Answers
2

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?)

UPDATE:

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.

If I understand your question, you are asking why shared object files have execute permissions, and that's because those are library files intended to be linked, and the code they contain is intended to be executed.