FS#65256 - [file] determines executables as shared libraries

Attached to Project: Arch Linux
Opened by Peter Weber (hoschi) - Friday, 24 January 2020, 15:08 GMT
Last edited by Levente Polyak (anthraxx) - Friday, 05 June 2020, 21:17 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Sébastien Luttringer (seblu)
Levente Polyak (anthraxx)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:
Hello!
Since file 5.38 regular executable are detected as shared libraries.


Additional info:
* package version(s): >= 5.38
* config and/or log files etc.:
"somexecutable: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=b99274f9b7940cd6dcb3bfe54ee713eaa3c7a41f, for GNU/Linux 3.2.0, not stripped
"
* link to upstream bug report, if any -

I'm not sure about the following:
Do Glib, Gio or Tracker detect executables through something, which is related to the file utility here? I downgraded file to 5.37, this fixed the behavior of 'file' itself. But applications like Nautilus still believe executable are shared libaries. As a consequence Nemiver (a debugger) doesn't detect executables as selectable files. I figured out, that I can workaround that through find-as-you-type in the file chooser, which allows to select any available file.

This task depends upon

Closed by  Levente Polyak (anthraxx)
Friday, 05 June 2020, 21:17 GMT
Reason for closing:  Fixed
Additional comments about closing:  5.38-3
Comment by Peter Weber (hoschi) - Friday, 24 January 2020, 15:16 GMT
I'm trying to report that to upstream, too. But until now I didn't received a registration mail from the upstream bugtracker.
Comment by Eli Schwartz (eschwartz) - Friday, 24 January 2020, 15:34 GMT Comment by Eli Schwartz (eschwartz) - Friday, 24 January 2020, 15:37 GMT Comment by Peter Weber (hoschi) - Friday, 24 January 2020, 15:41 GMT
Thanks for reporting upstream.
Comment by Sébastien Luttringer (seblu) - Friday, 24 January 2020, 16:15 GMT
I pushed a -3 in testing with the commit pointed by Eli reverted.
Comment by Levente Polyak (anthraxx) - Friday, 24 January 2020, 18:59 GMT
The reason for the unification is simple: There is no technical difference between a PIE executable and a shared object. On top in general shared libraries are distributed with the +x bit set, therefor libraries are mime types as application/x-pie-executable

5.37
/usr/bin/file --mime-type /usr/lib/libmagic.so.1.0.0
/usr/lib/libmagic.so.1.0.0: application/x-pie-executable

the unification makes sense as +x is not a appropriate way to detect if its a shared library or an application, which way around it should be is a matter of choice but technically PIE executables are not any different, except some subtile ways in relative references.

I see where the file folks are coming from, it feels more right to detect applications as shared objects instead of libraries as executables, but obviously it has some side effects
Comment by Eli Schwartz (eschwartz) - Friday, 24 January 2020, 19:50 GMT
I'm curious why /usr/lib/libmagic.so.1.0.0 has the execute bit set at all, then.

As for your analysis of this as a "unification", the file.git commit message stated "Don't depend on the execute bit to determine pie executable or shared object."

Don't "depend", does not sound like "remove support for the pie-executable type", it makes it sound like it's been removed in favor of other heuristics... but there are no other heuristics I can see.

So if that was the intention, it is a pretty confusing implementation.
Comment by Levente Polyak (anthraxx) - Friday, 24 January 2020, 20:33 GMT
well lets see what upstream says, but i have the feeling their commit subject is just not perfectly phrased but it may be intended as i described it.

@ .so having x bit set: well thats not file unique, 95% of the shared libs are always installed with +x... not that it wouldn't work without... but thats how it is *shrug*
Comment by Eli Schwartz (eschwartz) - Friday, 24 January 2020, 20:35 GMT
Fair enough, let's see.
Comment by Sébastien Luttringer (seblu) - Saturday, 25 January 2020, 10:02 GMT
Despite we have the signoffs, I'll wait before moving -3 to core.

Loading...