Bug 1581343

This looks similar to bug 1570246 comment #11.  Same question here: Is the output of file-5.33 technically incorrect?

The identification as PIE executable is a bit dubious, too.  If there's a PT_DYNAMIC segment but no PT_INTERP segment, it's a dynamic object without a program interpreter, and that really isn't an executable by any stretch.

Then we should probably revert the change in file-libs.  But at least with ld.so, I was able to execute the binary:

$ /lib64/ld-linux-x86-64.so.2
Usage: ld.so [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...]
You have invoked `ld.so', the helper program for shared library executables.
[...]

The funny thing is that we had bug #1296868 with exactly opposite request ;-)

(In reply to Kamil Dudka from comment #3)
> Then we should probably revert the change in file-libs.  But at least with
> ld.so, I was able to execute the binary:
> 
> $ /lib64/ld-linux-x86-64.so.2
> Usage: ld.so [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...]
> You have invoked `ld.so', the helper program for shared library executables.
> [...]

Yes, but ld.so is a special case (PT_DYNAMIC header, but statically linked PIE).  It is difficult to tell this from the usual DSO.

Thanks for feedback, in the meantime nominating PrioritizedBug

In addition to (or altnernatively to) restoring 'file' behavior, I'm open to any advice on alternatives on how best to identify loadable plugins vs shared libraries (what the gstreamer check is trying to do)

It seems to be caused by this commit:

https://github.com/file/file/commit/FILE5_32-87-g6876ebad

I will revert it and notify upstream about the breakage.

I have pushed the following commit to fix this bug:

https://src.fedoraproject.org/cgit/rpms/file.git/commit/?id=87dddb46

file-5.33-4.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-d1425c85a7

file-5.33-4.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-d1425c85a7

This is the response I got from file's upstream:

On Wednesday, May 23, 2018 6:18:04 PM CEST Christos Zoulas wrote:
> On May 23,  2:22pm, kdudka (Kamil Dudka) wrote:
> -- Subject: Re: file: multiple bugs in Fedora triggered by 'pie executable'
> | Yes, latest upstream snapshot prints a comma that file-5.33 did not. 
> | Still the problem remains that shared libraries are classified as pie
> | executables.
> That is a problem :-) So that we are all clear as to what's going on:
>
> 1. Shared objects (pie executables and shared libraries) use the same
> magic number, so they can't be told apart.
> 2. Many suggestions have been made on how to fix the problem, (check
> if they have an intepreter (breaks for static pie and glibc), check
> for entry point location (too fragile and difficult to code), etc.
> The jist of it is that nothing really works. Depending on the name
> to be libfoo.so simply does not work in the general case.
> 3. People kept asking for file(1) to differentiate. Reading in POSIX,
> file should say "executable" if the file is executable.
> http://pubs.opengroup.org/onlinepubs/007904975/utilities/file.html
> (STDOUT section in the table). So I've changed file just to do that.
>
> Are you installing your shared libraries with the execute bit set?
> If you do, then yes, they are pie executables. If you don't believe
> me, try to run them. Yes, most of them core-dump (so do buggy
> programs), but other's like glibc, or ld-linux-x86-64.so.2 work.
> If the kernel believes that they are PIE executables and
> attempts to execute them, then who is file(1) to disagree with the
> kernel :-)
>
> Now the real question is why do linux distributions install *some*
> of their shared libraries executable and others not? (I know the
> answer :-)
>
> Best,
>
> christos

Florian, could you please comment on that?  Is there anything better that upstream can use to distinguish shared libraries from dynamically linked executables?

I would have expected that you talk to gstreamer upstream why they need to use file to filter things.

Admittedly, it's really hard to tell the various ELF artifacts apart.  Current binutils adds DF_1_PIE to DT_FLAGS_1 for a PIE executable, so that would be a pretty strong indicator that something is actually an executable.  I would probably treat anything of type ET_DYN without the flag as a shared object.  That will give some false negatives, but for Fedora with the frequent mass rebuilds, it should be fairly accurate.

Thanks!  I will forward your reply to file's upstream.

The actual problem that prevented the new rule in file-5.33 from doing the right thing on Fedora is that all shared libraries have the executable bit set.  Could you please clarify why the executable bits are needed on all shared libraries on Fedora?

They do not seem to be needed on Ubuntu, for example.

(In reply to Kamil Dudka from comment #15)
> Thanks!  I will forward your reply to file's upstream.
> 
> The actual problem that prevented the new rule in file-5.33 from doing the
> right thing on Fedora is that all shared libraries have the executable bit
> set.  Could you please clarify why the executable bits are needed on all
> shared libraries on Fedora?

This could be something related to SELinux: Setting the x bit is an auditable event, and you can probably enforce that all machine code comes from files with the x bit using SELinux.

I know that Steve Grubb suggested to use the x bit on even more things.

RE: comment #14

gstreamer autoprovides script needs to be able to differentiate between (gstreamer) plugins and libraries, that's what 'file' is used for in this context.

Gory details,
https://src.fedoraproject.org/rpms/gstreamer/blob/master/f/gstreamer.prov

Suggestions welcome for anything that's better than the status quo (see linked bug #1581325 )

Do all the gstreamer plug-ins use a common API/ABI?

If yes, what prevents you from using readelf to examine the symbols of interest?

For gstreamer improvements, please comment in the gstreamer bug (bug #1581325), not all gstreamer maintainers are watching this one.

The executable bit should never figure into what a file might be. I would say that the heuristics is wrong.

file-5.33-4.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.

Reopening per bug #1570246 comment #15.

follow-up commit:

https://src.fedoraproject.org/cgit/rpms/file.git/commit/?id=2ac456e8

file-5.33-5.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-a269744e01

file-5.33-5.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-a269744e01

file-5.33-5.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.