Shared library permissions in Debian-land and Red Hat-land

[Adam Williamson]

So, I just ran into an interesting issue talking over Fedora patches
with the upstream glew maintainer. glew installs its shared libraries
'manually', not using autotools / libtools; upstream installs them with
permissions of 0644, and we patch this to 0755. After talking to
upstream, they say they're following Debian conventions here; I don't
have a Debian-land system to confirm, but they say on Debian and Ubuntu,
all shared libs have 0644 permissions.

In Fedora, they have to have 0755 or the auto-provides / auto-depends
scripts don't work.

So, is it true that the convention is 0644 in Debian and 0755 in Red
Hat-land? If so, does anyone know why the difference, and if this needs
to stay different forever? Also, I presume neither of us is patching
several thousand shared library packages for this, so are the
permissions usually set by libtool or something similar, and that's
where the configuration is set?

I just want to understand the situation better :) Thanks to anyone who
knows about this. A cursory Google search didn't find any interesting
information. I see
http://serverfault.com/questions/173853/why-shared-libraries-on-linux-are... , but
it seems a little confused.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

[Tom Lane]

Adam Williamson <awilliam(a)redhat.com&gt; writes:
>  So, is it true that the convention is 0644 in Debian and 0755 in Red
>  Hat-land? If so, does anyone know why the difference, and if this needs
>  to stay different forever? Also, I presume neither of us is patching
>  several thousand shared library packages for this, so are the
>  permissions usually set by libtool or something similar, and that's
>  where the configuration is set? 
I don't know all that much about the conventions for this under Linux,
but I'm familiar with other Unix-oid platforms where shared libraries
*must* have execute permission or they flat out don't work.  (HPUX is
that way for sure, and I think most BSDen as well.)  So it would not be
surprising for upstreams to prefer to install 0755 everywhere for
portability.  I think Debian is on the wrong side here, if your
informant is correct about their policy in the first place ...

			regards, tom lane

[Richard W.M. Jones]

On Thu, Mar 24, 2011 at 12:31:14AM -0400, Tom Lane wrote:
>  Adam Williamson <awilliam(a)redhat.com&gt; writes:
>  > So, is it true that the convention is 0644 in Debian and 0755 in Red
>  > Hat-land? If so, does anyone know why the difference, and if this needs
>  > to stay different forever? Also, I presume neither of us is patching
>  > several thousand shared library packages for this, so are the
>  > permissions usually set by libtool or something similar, and that's
>  > where the configuration is set?
>  
>  I don't know all that much about the conventions for this under Linux,
>  but I'm familiar with other Unix-oid platforms where shared libraries
>  *must* have execute permission or they flat out don't work. 
Don't forget also that shared libraries can be executable programs:

$ /lib64/libc.so.6 
GNU C Library development release version 2.13.90, by Roland McGrath et al.
Copyright (C) 2011 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.0 20110301 (Red Hat 4.6.0-0.11).
Compiled on a Linux 2.6.38 system on 2011-03-07.
Available extensions:
	  Support for some architectures added on, not maintained in glibc core.
	  The C stubs add-on version 2.1.2.
	  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
	  RT using linux kernel aio
libc ABIs: UNIQUE IFUNC
For bug reporting instructions, please see:
<http://www.gnu.org/software/libc/bugs.html>;.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora

[Peter Lemenkov]

2011/3/24 Adam Williamson <awilliam(a)redhat.com&gt;:
>  So, I just ran into an interesting issue talking over Fedora patches
>  with the upstream glew maintainer. glew installs its shared libraries
>  'manually', not using autotools / libtools; upstream installs them with
>  permissions of 0644, and we patch this to 0755. After talking to
>  upstream, they say they're following Debian conventions here; I don't
>  have a Debian-land system to confirm, but they say on Debian and Ubuntu,
>  all shared libs have 0644 permissions. 
I think they require 0644 only for dlopened libraries. This also
confuses me because I can dlopen objects with either 0644 or 0755
permissions. Unfortunately rpm dependency checker requires that all
library objects must be 0755.
-- 
With best regards, Peter Lemenkov.

[John Reiser]

>   they say on Debian and Ubuntu,
>  all shared libs have 0644 permissions. 
What they say is incorrect.

I have Ubuntu 10.10 i686:
-rwxr-xr-x 1 root root 1421892 2011-01-21 15:08 /lib/libc-2.12.1.so

I have Ubuntu 10.4 x86_64:
-rwxr-xr-x 1 root root 1405508 2011-01-21 14:25 /lib32/libc-2.11.1.so
-rwxr-xr-x 1 root root 1577632 2011-01-21 14:23 /lib64/libc-2.11.1.so
-rwxr-xr-x 1 root root 1577632 2011-01-21 14:23 /lib/libc-2.11.1.so

I have Ubuntu 9.10 i686:
-rwxr-xr-x 1 root root 1335560 2010-05-21 01:17 /lib/libc-2.10.1.so

I have Ubuntu 8.04 i686:
-rwxr-xr-x 1 root root 1274092 2010-10-21 20:33 /lib/libc-2.7.so

I have Ubuntu 7.10 i686:
-rwxr-xr-x 1 root root 1249520 2007-10-24 18:03 /lib/libc-2.6.1.so

I have Ubuntu 7.04 i686:
-rwxr-xr-x 1 root root 1249520 2007-10-24 18:03 /lib/libc-2.6.1.so

I have Debian [kernel 2.6.18-6] x86_64:
-rwxr-xr-x 1 root root 1212720 2010-01-17 04:36 /lib32/libc-2.3.6.so
-rwxr-xr-x 1 root root 1286104 2010-01-17 04:36 /lib64/libc-2.3.6.so
-rwxr-xr-x 1 root root 1286104 2010-01-17 04:36 /lib/libc-2.3.6.so

--

[Jakub Jelinek]

On Wed, Mar 23, 2011 at 09:52:24PM -0700, John Reiser wrote:
>  >  they say on Debian and Ubuntu,
>  > all shared libs have 0644 permissions.
>  
>  What they say is incorrect. 
Well, given that libc.so and ld.so are shared libraries with
with meaningful e_entry, so you can actually run
/lib/ld-2.*.so or /lib/libc-2.*.so,
those definitely should be 755.  The question is about libraries
which just segfault when you try to exec them (most of the shared
libraries).

>  I have Ubuntu 10.10 i686:
>  -rwxr-xr-x 1 root root 1421892 2011-01-21 15:08 /lib/libc-2.12.1.so 
	Jakub

[Ville Skyttä]

On 03/24/2011 06:52 AM, John Reiser wrote:
> >  they say on Debian and Ubuntu,
> > all shared libs have 0644 permissions.
>  
>  What they say is incorrect.
>  
>  I have Ubuntu 10.10 i686:
>  -rwxr-xr-x 1 root root 1421892 2011-01-21 15:08 /lib/libc-2.12.1.so 
[...snip more
libc examples...]

libc is probably a special case because it actually does useful things
when executed.  The vast majority of shared libs are not executable on a
Debian 6.0 box I just had a look at.

[Przemek Klosowski]

On 03/24/2011 03:28 AM, Ville Skyttä wrote:
>  On 03/24/2011 06:52 AM, John Reiser wrote:
> >>   they say on Debian and Ubuntu,
> >> all shared libs have 0644 permissions.
> >
> > What they say is incorrect.
> >
> > I have Ubuntu 10.10 i686:
> > -rwxr-xr-x 1 root root 1421892 2011-01-21 15:08 /lib/libc-2.12.1.so
>  [...snip more libc examples...]
>
>  libc is probably a special case because it actually does useful things
>  when executed.  The vast majority of shared libs are not executable on a
>  Debian 6.0 box I just had a look at. 
FWIW, on my F14 all the .so libs in /lib are executable, and all but 
three segfault (and trigger abrt) when executed. Besides the already 
mentioned libc-2.13.so and ld-2.13.so, only libpthread-2.13.so
runs successfully to print a legal notice followed by 'Forced unwind 
support included."

[Adam Williamson]

On Thu, 2011-03-24 at 11:59 -0400, Przemek Klosowski wrote:
>  On 03/24/2011 03:28 AM, Ville Skyttä wrote:
>  > On 03/24/2011 06:52 AM, John Reiser wrote:
>  >>>   they say on Debian and Ubuntu,
>  >>> all shared libs have 0644 permissions.
>  >>
>  >> What they say is incorrect.
>  >>
>  >> I have Ubuntu 10.10 i686:
>  >> -rwxr-xr-x 1 root root 1421892 2011-01-21 15:08 /lib/libc-2.12.1.so
>  > [...snip more libc examples...]
>  >
>  > libc is probably a special case because it actually does useful things
>  > when executed.  The vast majority of shared libs are not executable on a
>  > Debian 6.0 box I just had a look at.
>  
>  FWIW, on my F14 all the .so libs in /lib are executable, and all but 
>  three segfault (and trigger abrt) when executed. Besides the already 
>  mentioned libc-2.13.so and ld-2.13.so, only libpthread-2.13.so
>  runs successfully to print a legal notice followed by 'Forced unwind 
>  support included." 
Well, yes - that's the whole point of this thread: they're executable on
Fedora systems, not on Debian systems.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

[Przemek Klosowski]

On 03/24/2011 12:50 PM, Adam Williamson wrote:

> > FWIW, on my F14 all the .so libs in /lib are executable, and all
> but
> > three segfault (and trigger abrt) when executed. Besides the already
> > mentioned libc-2.13.so and ld-2.13.so, only libpthread-2.13.so
> > runs successfully to print a legal notice followed by 'Forced unwind
> > support included."
>
>  Well, yes - that's the whole point of this thread: they're executable on
>  Fedora systems, not on Debian systems. 
Sorry I was being too tentative. I meant to point out that the 755 perms 
don't seem to do anything useful (except possibly for ld.so, which I 
still don't quite understand what it is), and have definite negative 
effects (abrt noise). Therefore, I was going to suggest that we change 
them to 644.

[Kevin Kofler]

Przemek Klosowski wrote:
>  Sorry I was being too tentative. I meant to point out that the 755
> perms
>  don't seem to do anything useful (except possibly for ld.so, which I
>  still don't quite understand what it is), and have definite negative
>  effects (abrt noise). Therefore, I was going to suggest that we change
>  them to 644. 
You'd need to fix our debuginfo extraction scripts first.

        Kevin Kofler

[Kevin Kofler]

Adam Williamson wrote:
>  So, I just ran into an interesting issue talking over Fedora patches
>  with the upstream glew maintainer. glew installs its shared libraries
>  'manually', not using autotools / libtools; upstream installs them with
>  permissions of 0644, and we patch this to 0755. After talking to
>  upstream, they say they're following Debian conventions here; I don't
>  have a Debian-land system to confirm, but they say on Debian and Ubuntu,
>  all shared libs have 0644 permissions. 
This is true. AFAIK, the Debian policy is because those shared libraries 
crash when some idiot tries to run them as programs.

>  In Fedora, they have to have 0755 or the auto-provides /
> auto-depends
>  scripts don't work. 
This is also true.

>  So, is it true that the convention is 0644 in Debian and 0755 in Red
>  Hat-land? 
Yes, unfortunately. :-(

>  If so, does anyone know why the difference, 
See above.

>  and if this needs to stay different forever? 
I don't know, but right now it needs to be different in any case. :-(

I wonder if it would be possible to fix the kernel so that running a shared 
library does not crash, but give a meaningful error message, and if Debian 
would change their policy then.

>  Also, I presume neither of us is patching several thousand shared
> library
>  packages for this, so are the permissions usually set by libtool or
>  something similar, and that's where the configuration is set? 
I don't know how it works in autotools, but in CMake, they explicitly check 
if the system has an /etc/debian_version file and install the .so file as 
644 in that case and 755 otherwise:
http://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/Platform/Linux.cmake...

        Kevin Kofler

[David Howells]

Kevin Kofler <kevin.kofler(a)chello.at&gt; wrote:

>  I wonder if it would be possible to fix the kernel so that running a
> shared 
>  library does not crash, but give a meaningful error message, and if Debian 
>  would change their policy then. 
As far as the kernel is concerned, these shared libraries are executable, can
be parsed and have an entry point that isn't 0.  Why shouldn't it try and
execute them?

I don't see anything particularly useful that would indicate that ld-linux and
libc can be run, but that libkeyutils, for example, can't.  Unlike
libkeyutils, libc has a PHDR program header (as does, say, /bin/ls), but
ld-linux _doesn't_, so you can't use that as a key.

David

[drago01]

On Thu, Mar 24, 2011 at 7:08 PM, Kevin Kofler <kevin.kofler(a)chello.at&gt; wrote:
>  Adam Williamson wrote:
> > So, I just ran into an interesting issue talking over Fedora patches
> > with the upstream glew maintainer. glew installs its shared libraries
> > 'manually', not using autotools / libtools; upstream installs them with
> > permissions of 0644, and we patch this to 0755. After talking to
> > upstream, they say they're following Debian conventions here; I don't
> > have a Debian-land system to confirm, but they say on Debian and Ubuntu,
> > all shared libs have 0644 permissions.
>
>  This is true. AFAIK, the Debian policy is because those shared libraries
>  crash when some idiot tries to run them as programs. 
Why does that matter?
They run them notice the crash and learn from it. It is not like
running shared libraries as programs is an every day task.
This is really a fringe corner case and should simply be ignored it is
not worth basing distribution policy around that.

[John Reiser]

> > This is true. AFAIK, the Debian policy is because those shared
> libraries
> > crash when some idiot tries to run them as programs.
>  
>  Why does that matter? 
Some Debian maintainer(s) got tired of getting bug reports for this case.

>  They [the users] run them notice the crash and learn from it. 
It was [is] a resource drain on the project as a whole when the unknowledgeable
user does not think enough before filing a bug report.  Having the shell
give a [localized!] message for ENOEXEC is even instructive.

--