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=6490dd1e5108168743bc45d039f68d677334 966e;hb=HEAD#l21

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

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

Kevin Kofler <kevin.kofler@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

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

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

>> 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

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

On Thu, Mar 24, 2011 at 7:08 PM, Kevin Kofler <kevin.kofler@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

On Tue, Mar 29, 2011 at 10:32 AM, Hans de Goede <hdegoede@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

>> 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.

--
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel