[Bug 1747711] Re: file mis-identifies modern executables as application/x-sharedlib

[Chris Billington]

Has this been fixed upstream? Looking at the changelog, there has been a
related change, but I'm not sure if it resolves the issue yet, it now
says they're both executables.

https://github.com/file/file/blob/219846094c7593e27453e62855e61181089c48cf/ChangeLog


file 5.3.3:

python3.6: ELF 64-bit LSB pie executable x86-64, version 1 (SYSV),
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for
GNU/Linux 2.4.0, with debug_info, not stripped

libpython3.6m.so.1.0: ELF 64-bit LSB pie executable x86-64, version 1
(SYSV), dynamically linked, with debug_info, not stripped

file 5.3.2:

python3.6: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV),
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for
GNU/Linux 2.4.0, with debug_info, not stripped

libpython3.6m.so.1.0: ELF 64-bit LSB shared object, x86-64, version 1
(SYSV), dynamically linked, with debug_info, not stripped

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to file in Ubuntu.
https://bugs.launchpad.net/bugs/1747711

Title:
  file mis-identifies modern executables as application/x-sharedlib

Status in file package in Ubuntu:
  Confirmed

Bug description:
  file doesn't recognize modern PIE (Position Independent Executable)
  x86 executables as such, reporting them as “application/x-sharedlib”.
  Consequently, only non-PIE executables can be opened in graphical file
  managers such as nautilus. This may cause a minor (?) security risk if
  a commonly-published workaround is attempted.

  Expected behaviour:

      $ echo "int main() { return 0; }" > foo.c
      $ gcc -o foo foo.c
      $ file foo
      foo: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=6e7749f995a89a53f74ec29d3c16fcf3f56be90f, not stripped
      $ file --mime-type foo
      foo: application/x-executable

  Actual behaviour:

      $ echo "int main() { return 0; }" > foo.c
      $ gcc -o foo foo.c
      $ file foo
      foo: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=6e7749f995a89a53f74ec29d3c16fcf3f56be90f, not stripped
      $ file --mime-type foo
      foo: application/x-sharedlib

  Workaround (unsafe?):

      $ echo "int main() { return 0; }" > foo.c
      $ gcc -o foo-nopie foo.c -no-pie
      $ file foo-nopie
      foo-nopie: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=3eb8c581f43c19997e3c828f5a9730dbdc794470, not stripped
      $ file --mime-type foo-nopie
      foo-nopie: application/x-executable

  gcc now defaults to building with PIE enabled for security reasons.

  Also affects: nautilus (and likely other graphical file managers like
  those on Lubuntu) - because nautilus uses mime-type to determine if a
  file is executable, double-click to run a program no longer works.

  Also noted on: Gnome Bugs -
  https://bugzilla.gnome.org/show_bug.cgi?id=737849 (2014) - before PIE
  became the default build option.

  This may be an upstream issue. This may not affect architectures
  outside x86.*

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: file 1:5.32-1
  ProcVersionSignature: Ubuntu 4.13.0-32.35-generic 4.13.13
  Uname: Linux 4.13.0-32-generic x86_64
  ApportVersion: 2.20.7-0ubuntu3.7
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Tue Feb  6 11:21:20 2018
  InstallationDate: Installed on 2017-05-11 (270 days ago)
  InstallationMedia: Ubuntu-GNOME 17.04 "Zesty Zapus" - Release amd64 (20170412)
  SourcePackage: file
  UpgradeStatus: Upgraded to artful on 2017-10-21 (108 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/file/+bug/1747711/+subscriptions