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?

  • 4
    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. Jun 12, 2012 at 22:08
  • If they segfault, they are probably minor bugs. I'd report them if you come across them. What is the distribution? Jun 15, 2012 at 10:02
  • 2
    @Faheem: Not having a main() symbol as an entry point is not a minor bug, but a fundamental design choice. You missed my point. Jun 15, 2012 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. Jun 15, 2012 at 10:44
  • 1
    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, 2017 at 4:33

2 Answers 2


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. Sep 18, 2012 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 Jun 22, 2016 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. Dec 3, 2017 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:
  • 13
    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. Jun 12, 2012 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, 2012 at 12:40
  • 6
    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.
    – user732
    Jun 12, 2012 at 15:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .