Two (possibly related) issue w/ 4.18.x rpmbuild

[Panu Matilainen]

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 -