Debian – or should not shared libraries be executable (e.g. Red Hat vs Debian)

debiandynamic-linkinglibrariesrhel

This is almost but not quite a duplicate of "Why are .so files executable?".

I note that on Red Hat based systems shared libraries have execute permission but on Debian they do not.

Logically shard libraries are not executable themselves unless they are by design (through clever linking). However, the code they contain is executed. So its a bit of a grey area.

There is an interesting artic

The linked question suggests its for historical reasons and also that it is a requirement on some Unix-like OSs like HP-UX.

I would like to understand the reason why Debian and Red Hat differ here in a bit more depth.

Which system changed and why?

What is the situation on BSD?

Are there any possible security considerations?

Update: 26-Oct-2017

Here is what Red Hat had to say on the subject (emphasis mine):

Setting an executable bit on libraries does not have any effect other than they could be executed from a shell. The shared libraries in Linux are in a format called ELF, which stands for Executable and Linkable Format. This is the format for both executable files and shared libraries, so that is the reason why libraries are marked with an executable bit. It is worth noting that GCC creates shared libraries with the executable bit set by default.

Removing the executable bit does not have any side effects (other than not being able to run certain libraries to display their information, such as libc), since the dynamic loader does not care about the libraries' permissions: it instead maps parts of the library to parts of memory, and those that require execution are mapped to a memory area previously marked as PROT_EXEC.

So as pointed out it is the Debian policy that has libraries installed as non-executable. I suppose that gcc (or rather ld) being platform independent errs on the side of caution by making libraries them executable by default?

There is an interesting article here: https://www.technovelty.org/linux/shared-libraries-and-execute-permissions.html

See also https://stackoverflow.com/questions/6299395/gcc-generates-shared-object-with-execute-permissions

Best Answer

Debian changed this back in 1997, in Policy version 2.2 (see #7129, although that doesn’t give much detail at all and I haven’t found any other discussion); the reason is given thus in current versions of Policy:

Shared libraries should not be installed executable, since the dynamic linker does not require this and trying to execute a shared library usually results in a core dump.

So it’s really about managing expectations, and the principle of least surprise: don’t mark something as executable if executing it isn’t useful. On Debian and its derivatives, the only libraries which are supposed to be executable are those which do something sensible when executed (such as the C library, libpthread, and of course the dynamic linker).

On FreeBSD and OpenBSD, at least, shared libraries from the operating system are not executable. On OpenBSD this is also generally true of shared libraries in /usr/local. On FreeBSD, shared libraries in /usr/local from ports and packages are often executable. (Thanks to JdeBP for the BSD-related information.)

On Linux, I don’t think there are any particular security considerations (at least, not on a basic Linux system), because running a library doesn’t require its executable bit to be set (you can run it using the dynamic linker).

Related Question