On 2018-02-07 02:54 PM, Sergio Durigan Junior wrote:
Unfortunately it seems that "file" is not "properly maintained" in the sense that the project doesn't have a trivial way to receive contributions.
But it does help when list members like Chris know the original developer and can get you the contact details of the most-upstream-of-all maintainer! Unfortunately, the maintainer doesn't consider it a bug:
Thanks for the bug report; only this is not a bug. PIE executables are shared objects. There is no way to tell them apart from shared objects.
So we're kind of stuck.
In this scenario, what I recommend is to file a bug downstream (against Debian's "file", for example), and ask the maintainer to forward the fix upstream.
I did, with Ubuntu: https://bugs.launchpad.net/ubuntu/+source/file/+bug/1747711 Unfortunately, if this really isn't something that the file (1) maintainers can fix, I'm going to have to file bugs with the Gnome Files/Nautilus (Gnome), PCManFM (LXDE), Konqueror (KDE) and Thunar (XFCE) folks to advise them not to rely on magic (5) alone now.
It seems to me that perhaps the graphical UI could rely not only on the MIME type of a file, but also if it is marked as executable or not.
That would be sensible, yes.
Debian explicitly advises (in the form of a lintian error) against having the executable bit set for libraries, so only executable files will have +x.
But now we'll need to fix lintian, as Debian binaries are being supplied as shared objects. If you've got a recently-updated Debian Stretch distro running, binaries such as /usr/bin/curl are PIE shared objects …
Yeah, this is not really a workaround per se, because it disables PIE when compiling the binary. Having PIE enabled is a nice security feature, so I would recommend against doing that.
For sure. But since naïve users (and me ☺) use graphical file managers, and the only way to get binaries to run these days is to make them non-PIE, we have a security problem. cheers, Stewart