[GTALUG] 'file' maintainer? (or fun with PIE and magic)

[Sergio Durigan Junior]

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/