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/ --- Talk Mailing List [email protected] https://gtalug.org/mailman/listinfo/talk
