Why have almost all the shared libraries in /usr/lib/ have the executable permission bit set? I don't see any use case for executing them. Some do manage to hook-up some form of main function to print a short copyright and version note, but many don't do even that and segfault upon execution.

So, what's the point of setting this x? Must all library packagers do that? What will happen if I dlopen() a shared library that has 0644 permissions?

  • 3
    On what OS (if Linux, what distribution)? On Debian squeeze, the only executable shared libraries in /lib and /usr/lib are libc and libpthread, and both print a copyright notice when executed. – Gilles 'SO- stop being evil' Jun 12 '12 at 22:08
  • If they segfault, they are probably minor bugs. I'd report them if you come across them. What is the distribution? – Faheem Mitha Jun 15 '12 at 10:02
  • @Faheem: Not having a main() symbol as an entry point is not a minor bug, but a fundamental design choice. You missed my point. – Tadeusz A. Kadłubowski Jun 15 '12 at 10:41
  • 2
    @Gilles: I have seen 755 as a default permission choice on RedHat-family Linux systems (Fedora and Centos), and on Solaris. – Tadeusz A. Kadłubowski Jun 15 '12 at 10:44
  • The premise of this question is not universally true. In fact it is false, as noted above, for Debian Linux; and also false for FreeBSD and for OpenBSD. – JdeBP Oct 25 '17 at 4:33

Under HP-UX, shared libraries are mapped into memory using mmap(), and all memory pages in the system have protection bits which are coupled with the kernel and processor hardware's memory page protection mechanisms. In order to execute the contents of any page of memory on the system, that page must have PROT_EXEC set - a useful feature to prevent data execution exploits.

The mmap() call uses the permission bits on the file it is about to map to define the protection bits of the mapped memory pages which are to contain it: rwx -> PROT_READ|PROT_WRITE|PROT_EXEC (from sys/mman.h). so in order for a shared library to be usable on HP-UX, the file containing the shared library must have execute permissions to insure that the mapped library also has execute permission.

A shared library with mode 644 on an HP-UX system will cause core dumps.

  • Possibly other Unix implementations use this feature as well. – Tadeusz A. Kadłubowski Sep 18 '12 at 6:41
  • > HP-UX (from "Hewlett Packard Unix") is Hewlett Packard Enterprise's proprietary implementation of the Unix operating system, based on UNIX System V – David 天宇 Wong Jun 22 '16 at 18:02
  • One other example is that creating rpm packages with separate debuginfo packages requires execute permissions on shared libraries otherwise find-debuginfo.sh skips processing them. – Domen Vrankar Dec 3 '17 at 19:09

Non-executable shared objects work fine, but libraries marked executable may also be runnable as standalone programs.

So, what's the point of setting this x?

None, unless you want them to emit version or other info

Must all library packagers do that?


What will happen if I dlopen() a shared library that has 0644 permissions?

You'll get a new shared object handle (so long as the file is readable etc.) ... the exec bit doesn't affect this

As to why libraries which aren't usable as standalone executables still have the exec bit set: this is probably just an artefact of the build system or link script used.

example output, just for reference:

$ /lib/i386-linux-gnu/libc.so.6
GNU C Library (Ubuntu EGLIBC 2.15-0ubuntu10) stable release version 2.15, by Roland McGrath et al.
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
Compiled by GNU CC version 4.6.3.
Compiled on a Linux 3.2.14 system on 2012-04-19.
Available extensions:
    crypt add-on version 2.1 by Michael Glad and others
    GNU Libidn by Simon Josefsson
    Native POSIX Threads Library by Ulrich Drepper et al
For bug reporting instructions, please see:
  • 11
    Most .so libraries simply segfault because they do not have anything resembling normal main() entry point. Libc is an outlier. Its developers did this note as an extra functionality. Simple chmod a+x of any other library will not give you this functionality` I still don't see the point of setting +x for all libraries. – Tadeusz A. Kadłubowski Jun 12 '12 at 11:15
  • Agreed, and probably only those .sos which can be executed should be marked as such. I'll amend my answer to avoid implying that everything with the exec bit set is really a standalone executable. – Useless Jun 12 '12 at 12:40
  • 5
    The "ldd" command is usually a sh script that invokes the dynamic linker, ld-linux-x86-64.so.2, or /lib/ld-linux.so.2 or some such. The dynamic linker is always a shared object. – Bruce Ediger Jun 12 '12 at 15:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.