Re: Shared library permissions in Debian-land and Red Hat-land
Hi, On 03/28/2011 10:11 PM, Nathaniel McCallum wrote: On Mon, 2011-03-28 at 16:05 -0400, Przemek Klosowski wrote: On 03/24/2011 02:49 PM, Kevin Kofler wrote: On Thursday 24 March 2011, you wrote: Hmm, I thought there'd be a catch. What's executable permission needed for? Isn't that just reading/parsing? I can do some work but I am totally unfamiliar with this area. Files which aren't executable aren't even considered as candidates for being ELF files to extract debuginfo from. Without execute permission, you'd have to check EVERY SINGLE installed FILE for being ELF, that might be a significant performance hit. It'd have to be tried at least. OK, so executable permission is used as a tag for identifying ELF files. It's a little inelegant because there are some negative side effects from executing those non-executable files. If, hypothetically, we wanted to change that, is there any other way to reliably mark ELF files? I could think of those: - extended filesystem attributes? works but might be FS-dependent - make the files owned by a special ELF group - a system-level directory of ELF files maintained by e.g. RPM Well, technically you could still use +x for other non-shared library ELF files, you'd just also need to look for .so files. That seems to me the simplest solution and should still be fast since the filename is in the directory inode (which you have to read anyway). Note that while discussing things it would be good to fix the long standing rpm feature of auto generating provides for .so files even though they are intended for dl-opening only. Currently rpm needs to know if something is an elf shared object for 2 reasons: 1) To generate debuginfo 2) To generate an auto provides of the soname If we're going to make changes here I would really to see the heuristic for 2 changed from is it executable to does it live under /lib[64] or /usr/lib[64]. This will remove the need to add tons of provides filters to perl or python packages which contain some native bits. Yes this will break the provides generation for packages which install real / normal libraries under a different dir. Well good for them that moves the pain of dealing with special cases wrt auto Provides to the special cases, rather then making any packages which has plugins or other wise dlopen only shared objects deal with it. Also note that packages installing libraries under a different dir often do so, because they offer replacement libs for a system library (ie libGL from the binary nvidia driver from a 3th party repo) and in this case actually not having the Provides for the soname is the right thing to do! Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Shared library permissions in Debian-land and Red Hat-land
On Thu, Mar 24, 2011 at 7:08 PM, Kevin Kofler kevin.kof...@chello.at 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Shared library permissions in Debian-land and Red Hat-land
On Tue, Mar 29, 2011 at 10:32 AM, Hans de Goede hdego...@redhat.com wrote: If we're going to make changes here I would really to see the heuristic for 2 changed from is it executable to does it live under /lib[64] or /usr/lib[64]. This will remove the need to add tons of provides filters to perl or python packages which contain some native bits. Yes this will break the provides generation for packages which install real / normal libraries under a different dir. I guess that checking if the package also installs a config file into /etc/ld.so.conf.d/ and if it does, also checking the directories setup in the config file, would handle most of these cases. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Shared library permissions in Debian-land and Red Hat-land
On 03/24/2011 02:49 PM, Kevin Kofler wrote: On Thursday 24 March 2011, you wrote: Hmm, I thought there'd be a catch. What's executable permission needed for? Isn't that just reading/parsing? I can do some work but I am totally unfamiliar with this area. Files which aren't executable aren't even considered as candidates for being ELF files to extract debuginfo from. Without execute permission, you'd have to check EVERY SINGLE installed FILE for being ELF, that might be a significant performance hit. It'd have to be tried at least. OK, so executable permission is used as a tag for identifying ELF files. It's a little inelegant because there are some negative side effects from executing those non-executable files. If, hypothetically, we wanted to change that, is there any other way to reliably mark ELF files? I could think of those: - extended filesystem attributes? works but might be FS-dependent - make the files owned by a special ELF group - a system-level directory of ELF files maintained by e.g. RPM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Shared library permissions in Debian-land and Red Hat-land
On Mon, 2011-03-28 at 16:05 -0400, Przemek Klosowski wrote: On 03/24/2011 02:49 PM, Kevin Kofler wrote: On Thursday 24 March 2011, you wrote: Hmm, I thought there'd be a catch. What's executable permission needed for? Isn't that just reading/parsing? I can do some work but I am totally unfamiliar with this area. Files which aren't executable aren't even considered as candidates for being ELF files to extract debuginfo from. Without execute permission, you'd have to check EVERY SINGLE installed FILE for being ELF, that might be a significant performance hit. It'd have to be tried at least. OK, so executable permission is used as a tag for identifying ELF files. It's a little inelegant because there are some negative side effects from executing those non-executable files. If, hypothetically, we wanted to change that, is there any other way to reliably mark ELF files? I could think of those: - extended filesystem attributes? works but might be FS-dependent - make the files owned by a special ELF group - a system-level directory of ELF files maintained by e.g. RPM Well, technically you could still use +x for other non-shared library ELF files, you'd just also need to look for .so files. That seems to me the simplest solution and should still be fast since the filename is in the directory inode (which you have to read anyway). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Shared library permissions in Debian-land and Red Hat-land
Files which aren't executable aren't even considered as candidates for being
ELF files to extract debuginfo from.
Without execute permission, you'd have to check EVERY SINGLE installed FILE
for being ELF, that might be a significant performance hit. It'd have to be
tried at least.
The heuristic 0==memcmp(ELFMAG, file[0..3], SELFMAG) is 99.99% effective,
and never gives a false negative. The cost is {open+read} for checking ELFMAG,
vs {stat} for checking __S_IEXEC. Most of the cost of open() and stat()
is the same: looking up the filename. The cost of a 4-byte read() is small.
Therefore using ELFMAG costs about the same as using __S_IEXEC, as long as
the total number of execve() is nearly the same.
Implement as a filter: read file names from stdin, write the names of
the ELF files onto stdout:
find . -type f | ELF_filter | xargs extract_debuginfo
replacing
find . -type f -a -perm /u+x | xargs extract_debuginfo
--
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Shared library permissions in Debian-land and Red Hat-land
Kevin Kofler kevin.kof...@chello.at 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Shared library permissions in Debian-land and Red Hat-land
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Shared library permissions in Debian-land and Red Hat-land
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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Shared library permissions in Debian-land and Red Hat-land
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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Shared library permissions in Debian-land and Red Hat-land
On Thu, Mar 24, 2011 at 12:31:14AM -0400, Tom Lane wrote: Adam Williamson awill...@redhat.com 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Shared library permissions in Debian-land and Red Hat-land
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Shared library permissions in Debian-land and Red Hat-land
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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Shared library permissions in Debian-land and Red Hat-land
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;h=6490dd1e5108168743bc45d039f68d677334966e;hb=HEAD#l21 Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Shared library permissions in Debian-land and Red Hat-land
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Shared library permissions in Debian-land and Red Hat-land
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-executable , 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Shared library permissions in Debian-land and Red Hat-land
2011/3/24 Adam Williamson awill...@redhat.com: 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Shared library permissions in Debian-land and Red Hat-land
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 -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
