>>> So for mime types to distinguish, "file" needs to grow reporting of the INTERP presence.
Distinguish between shared libraries and PIC executables based on INTERP ELF header is not always correct. Consider following 2 exceptions: GLIBC main library libc-2.24.so This shared object has an INTERP header, which is /lib64/ld-linux-x86-64.so.2 in my system. However we usually considering it a shared library, not an executable. GLIBC dynamic linker ld-2.24.so This shared object doesn't have INTERP header because this object itself is an interpreter. It should be considered as an executable since it is useful to load and run GLIBC linked dynamic executables. This indicates a clear boundary between shared libraries and PIC executables just does not exist. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
