On 3/20/23 11:13, Florian Weimer wrote:
* Panu Matilainen:
Most shared libraries are NOT executable, and should not be packaged
as such. Which is why rpm automatically strips the executable flags
from those deemed only shared libraries via brp-elfperms script after
the install stage. glibc (ld*.so rather) being the special case of
course.
Huh. We need to install all shared objects as executable, otherwise
Linux security modules (e.g., SELinux with certain policies) will not
allow mapping them as PROT_EXEC, and nothing will work.
The ELF backend i binutils ld had a long-standing bug where it did not
set the ELF entrypoint to 0 on shared objects by default (marking them
as not directly executable). This bug has been fixed. However, the
kernel does not yet refuse to execute ELF shared objects which have no
ELF interpreter and entry point 0. That bug remains to be fixed.
These are the issues that need to be fixed to avoid confusing crashes.
Removing the executable bit is not the right approach.
Huh indeed. This is the first I ever hear about *any* of that. I've only
seen and heard various attemps by distros to avoid having to
unnecessarily set executable bits on libraries.
It's not a bad day when you learn something new...
So this would largely be Linux specific, and I guess LSM specific at
that. Seems the executable stripping is a "build root policy" for a
reason... and I realize now why none of the big distros have seen this
before: they all override rpm's default brp set and presumably haven't
been updated to run brp-elfperms at all.
I was just looking at this and found no way to persuade eu-elfclassify
to consider ld-*.so as an executable, which breaks it for what I thought
was the primary usecase. But clearly I'm missing more than a little in
the big picture here...
- Panu -
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxxxxx
http://lists.rpm.org/mailman/listinfo/rpm-list
