Shared library permissions

Matthew Burgess matthew at linuxfromscratch.org
Mon Aug 22 12:39:54 PDT 2005


Hi folks.

Does anyone know why shared libraries need the execute bit set on them? 
  My most recent build (gcc4-based) has most[1] *.so files installed 
with 755 permissions.  As it's so consistent, I'm assuming there is a 
reason for them to be executable.  Thanks to Tarek Ghaleb and Andrew 
Benton for highlighting the issue [2].

https://bugs.eclipse.org/bugs/show_bug.cgi?id=20305 states: "On HP, 
shared libraries need to have r-x permissions (no write).  On other
Unixes, shared libraries do not need execute permission."

http://docs.hp.com/en/B2355-90655/ch05s07.html backs up the HP-UX side 
of that, which is hardly useful in our case!

I think that 
http://www.ussg.iu.edu/hypermail/linux/kernel/0409.1/0625.html hints 
that the execute bit should be kept around even though it has no effect 
on x86 systems.

http://mail-index.netbsd.org/tech-pkg/2004/10/25/0011.html states 
"Classically, *all* shared objects, dlopen()ed or not, required execute
permission, because that permission was used to govern whether mmap()ed
pages could be marked executable."  This links in to Drepper's DSO Howto 
which also mentions mmap()ed pages and 
http://www.opensolaris.org/jive/thread.jspa?threadID=1353&tstart=0.

So, after all that, there's lots of anecdotal evidence that we should 
retain the execute permissions on shared libs, but nothing conclusive 
that it's *required* on modern Linux systems.  Can someone with far 
better googling skills (or just plain technical knowledge) be so good as 
to enlighten me, please?

Regards,

Matt

[1] Exceptions being: /lib/libproc-3.2.5.so (555), /usr/lib/libc.so 
(644), /usr/lib/libpthread.so (644), /usr/lib/preloadable_libintl.so 
(644), and Perl's modules (555)

[2] 
http://www.linuxfromscratch.org/pipermail/lfs-support/2005-August/028123.html



More information about the lfs-dev mailing list