Bug 1296868 - file/libmagic: PIE program incorrectly reported as shared object
file/libmagic: PIE program incorrectly reported as shared object
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: file (Show other bugs)
24
All Linux
unspecified Severity medium
: ---
: ---
Assigned To: Marek Cermak
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-01-08 04:53 EST by Yann Droneaud
Modified: 2017-09-06 17:33 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1296858
Environment:
Last Closed: 2017-07-25 09:31:26 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Yann Droneaud 2016-01-08 04:53:54 EST
+++ 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.
Comment 1 Yann Droneaud 2016-05-12 10:05:36 EDT
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)
Comment 2 Fedora Admin XMLRPC Client 2016-06-24 06:59:40 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 3 Marek Cermak 2017-07-25 09:31:26 EDT
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.
Comment 4 Yann Droneaud 2017-07-25 10:00:57 EDT
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.
Comment 5 Kamil Dudka 2017-07-25 11:25:15 EDT
(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
Comment 6 Yann Droneaud 2017-07-25 12:09:37 EDT
(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.
Comment 7 Kamil Dudka 2017-07-25 12:44:07 EDT
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.
Comment 8 Yann Droneaud 2017-07-25 12:50:03 EDT
(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.

Note You need to log in before you can comment on or make changes to this bug.