+++ This bug was initially created as a clone of Bug #1296858 +++ "file" command incorrectly report PIE program as shared object instead of executable: $ file bin-nopie bin-nopie: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=ee817f6d5d4f5635a981b1b837b1b0de3b16aacf, not stripped $ file bin-pie bin-pie: 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.6.32, BuildID[sha1]=439fc92838d4d0981f99dd967485e5b95a5a0e7b, not stripped As the file is not reported as executable, other programs relying on "file" guessing the file type will report PIE program as "application/x-sharedlib" instead of "application/x-executable" MIME type.
There's an upstream bug report at http://bugs.gw.com/view.php?id=404 "0000404: file reports position independent executables as mimetype application/x-sharedlib" (Found from https://bugzilla.gnome.org/show_bug.cgi?id=737849)
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
CLOSED AS NOT A BUG Justification ------------- $ gcc -Wall -o nopie-example foo.c $ file -b nopie-example ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=1238daecde7438bec2775c358f33035b6c29bae0, not stripped $ gcc -Wall -fPIE -pie -o pie-example foo.c $ file -b pie-example 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.6.32, BuildID[sha1]=abac3600fe871b1eb62df5240eebca58fee74c06, not stripped $ gcc -shared -fPIC -o shared-example.so foo.c $ file -b shared-example ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=72793b25abf834f15801c7db7d1cdbabb50b252c, not stripped PIE program has been reported as LSB shared object. Notice the difference in the interpreter part. $ eu-readelf -h pie-example | grep -i type Type: DYN (Shared object file) $ eu-readelf --strings=.interp pie-example String section [1] '.interp' contains 28 bytes at offset 0x238: [ 0] /lib64/ld-linux-x86-64.so.2 Therefore the output of file(1) corresponds with the output of eu-readelf command From header file in /usr/include/elf.h (also see http://www.skyfree.org/linux/references/ELF_Format.pdf) #define EI_NIDENT (16) typedef struct { unsigned char e_ident[EI_NIDENT]; /* Magic number and other info */ lf32_Half e_type; /* Object file type */ . . . } where e_type is value on offset 16 and identifies the object file type : e.g ET_DYN 3 Shared object file $ od -t cd1 pie-example -w17 | head -n4 0000000 177 E L F 002 001 001 \0 \0 \0 \0 \0 \0 \0 \0 \0 003 127 69 76 70 2 1 1 0 0 0 0 0 0 0 0 0 3 0000021 \0 > \0 001 \0 \0 \0 0 005 \0 \0 \0 \0 \0 \0 @ \0 0 62 0 1 0 0 0 48 5 0 0 0 0 0 0 64 0 Notice the e_type of value 3 in the last column ( offset 16 ) And in the elf magic file >16 leshort 2 executable, !:mime application/x-executable >16 leshort 3 shared object, !:mime application/x-sharedlib The magic file hence matches the format specification as stated in the elf.h and the reference documentation. Though the resemblence of the output of file(1) command from PIE and shared lib files is confusing and problematic, it matches the specification of the format and therefore should not be considered to be a bug.
Hi, (In reply to Marek Cermak from comment #3) > > $ gcc -Wall -fPIE -pie -o pie-example foo.c > $ file -b pie-example > 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.6.32, > BuildID[sha1]=abac3600fe871b1eb62df5240eebca58fee74c06, not stripped > > $ gcc -shared -fPIC -o shared-example.so foo.c > $ file -b shared-example > ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, > BuildID[sha1]=72793b25abf834f15801c7db7d1cdbabb50b252c, not stripped > > PIE program has been reported as LSB shared object. Notice the difference in > the interpreter part. > $ file /lib64/libc-2.25.so /lib64/libc-2.25.so: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=e8ee1bfe27b4fc40bce3caf3902d15595c5650b9, for GNU/Linux 2.6.32, not stripped Notice the interpreter part. It's obviously a library, but has an interpreter. > > Though the resemblence of the output of file(1) command from PIE and shared > lib files is confusing and problematic, it matches the specification of the > format and therefore should not be considered to be a bug. OK.
(In reply to Yann Droneaud from comment #4) > $ file /lib64/libc-2.25.so > /lib64/libc-2.25.so: ELF 64-bit LSB shared object, x86-64, version 1 > (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, > BuildID[sha1]=e8ee1bfe27b4fc40bce3caf3902d15595c5650b9, for GNU/Linux > 2.6.32, not stripped > > Notice the interpreter part. It's obviously a library, but has an > interpreter. I am able to execute the file: % /lib64/libc-2.25.so GNU C Library (GNU libc) stable release version 2.25, by Roland McGrath et al. Copyright (C) 2017 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 7.1.1 20170622 (Red Hat 7.1.1-3). Available extensions: crypt add-on version 2.1 by Michael Glad and others GNU Libidn by Simon Josefsson Native POSIX Threads Library by Ulrich Drepper et al BIND-8.2.3-T5B libc ABIs: UNIQUE IFUNC For bug reporting instructions, please see: <http://www.gnu.org/software/libc/bugs.html>. % echo $? 0
(In reply to Kamil Dudka from comment #5) > (In reply to Yann Droneaud from comment #4) > > $ file /lib64/libc-2.25.so > > /lib64/libc-2.25.so: ELF 64-bit LSB shared object, x86-64, version 1 > > (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, > > BuildID[sha1]=e8ee1bfe27b4fc40bce3caf3902d15595c5650b9, for GNU/Linux > > 2.6.32, not stripped > > > > Notice the interpreter part. It's obviously a library, but has an > > interpreter. > > I am able to execute the file: > Yes, that's why it's funny. Now: $ file /lib64/ld-2.25.so /lib64/ld-2.25.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=5ed8a951113e99fc0dd460281b4cdd5be22e4b53, not stripped There's no interpreter, it's not an executable, but you can execute it too.
Indeed. I see you already mentioned it on the freedesktop bug. I agree that it is rather an exception for the very specific program that is used as interpreter for pretty much all ELF 64-bit executables in the distribution.
(In reply to Kamil Dudka from comment #7) > Indeed. I see you already mentioned it on the freedesktop bug. I agree > that it is rather an exception for the very specific program that is used as > interpreter for pretty much all ELF 64-bit executables in the distribution. It's a pity "file" cannot reliably report that an ELF file is a program that can be executed. Anyway, as noted in comment #3, "file" reports only what ELF standard defines.