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

[Hans de Goede]

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