Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.
Sign up to join this community
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?
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.
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?
No
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
PARTICULAR PURPOSE.
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
BIND-8.2.3-T5B
libc ABIs: UNIQUE IFUNC
For bug reporting instructions, please see:
<http://www.debian.org/Bugs/>.
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
.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.
/liband/usr/libare libc and libpthread, and both print a copyright notice when executed.main()symbol as an entry point is not a minor bug, but a fundamental design choice. You missed my point.