On Thursday, February 08 2018, Stewart C. Russell via talk wrote:
On 2018-02-07 02:54 PM, Sergio Durigan Junior wrote:
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.
Yeah, I tend to agree with the maintainer here, although I find the term "shared object" a bit overloaded. There are executable and non-executable shared objects (see below), so maybe "file" could be more explicit.
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.
While it is questionable whose bug this is, I think it's really with these tools that the discussion should begin. However, it's interesting to see the first reply of <https://bugzilla.gnome.org/show_bug.cgi?id=737849> (a bug that is linked in your bug report): nautilus is not an application launcher, really. But using a desktop file to launch your app works just fine here; using both gtk-launch or nautilus. What problem are you seeing with that ? So I guess there may be a different interpretation of what "executing a file using a file manager" means. There's also a very interesting comment later on (comment #10), saying that Nautilus doesn't rely on "file", but rather on other libraries which provide the "MIME guessing" for it.
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 …
No fix is needed for lintian, because a shared library is not the same thing as an executable shared object. The latter has a PT_INTERP entry which specifies that it needs an interpreter to run (in the case of an executable, it's ld.so). So the rule still applies: shared libraries can't have their execution bit set, but executable shared objects can.
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.
Agreed. Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/