file mis-identifies modern executables as application/x-sharedlib
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
file (Ubuntu) |
Confirmed
|
Undecided
|
Unassigned |
Bug Description
file doesn't recognize modern PIE (Position Independent Executable) x86 executables as such, reporting them as “application/
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/
$ file --mime-type foo
foo: application/
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/
$ file --mime-type foo
foo: application/
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/
$ file --mime-type foo-nopie
foo-nopie: application/
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:/
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
ProcVersionSign
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)
information type: | Private Security → Public Security |
description: | updated |
tags: | added: bionic |
tags: | added: rls-bb-incoming |
tags: |
added: rls-bb-notfixing removed: rls-bb-incoming |
It is also an issue on bionic:
$ schroot -u root -c bionic-amd64 amd64)root@ impulse: /tmp# echo "int main() { return 0; }" > foo.c amd64)root@ impulse: /tmp# gcc -o foo foo.c amd64)root@ impulse: /tmp# file foo ld-linux- x86-64. so.2, for GNU/Linux 3.2.0, BuildID[ sha1]=5222fe7f5 f12ee8d286b84f9 3c981cab98ad382 a, not stripped
(bionic-
(bionic-
(bionic-
foo: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/
But not on xenial:
$ schroot -u root -c xenial-amd64 amd64)root@ impulse: /tmp# echo "int main() { return 0; }" > foo.c amd64)root@ impulse: /tmp# gcc -o foo foo.c amd64)root@ impulse: /tmp# file foo ld-linux- x86-64. so.2, for GNU/Linux 2.6.32, BuildID[ sha1]=5a079b5be 569b3e0527b9685 f1c7811fb193d37 c, not stripped
(xenial-
(xenial-
(xenial-
foo: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/
Using gcc from xenial and file from bionic though the file is identified as an executable so I don't think its file.