GCC compiles programs to shared object instead of executable, preventing GUI file managers from executing programs

Bug #1639531 reported by Olathe on 2016-11-06
78
This bug affects 17 people
Affects Status Importance Assigned to Milestone
gcc-defaults
Unknown
Medium
shared-mime-info
Unknown
Medium
shared-mime-info (Ubuntu)
High
Unassigned
Declined for Yakkety by Matthias Klose

Bug Description

Release of Ubuntu being used
============================

Description: Ubuntu 16.10
Release: 16.10

Version of the package being used
=================================

gcc:
  Installed: 4:6.1.1-1ubuntu2
  Candidate: 4:6.1.1-1ubuntu2
  Version table:
 *** 4:6.1.1-1ubuntu2 500
        500 http://archive.ubuntu.com/ubuntu yakkety/main amd64 Packages
        100 /var/lib/dpkg/status

What was expected
=================

Programs compiled using `gcc -o program program.c` should be runnable by double-clicking them from a GUI file manager.

Compiling a simple program (`void main() { }`) using Xubuntu 16.04's current version of `gcc` (`gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.2)`) produces the following output from `/usr/bin/file program`:

    program: 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]=signature_here, not stripped

This is correct behavior, allowing the executables to run from Nautilus and Thunar.

What happened instead
=====================

Programs compiled using `gcc -o program program.c` are not runnable by double-clicking them from a GUI file manager, even though they are runnable from the terminal.

Compiling a simple program (`void main() { }`) using the current version of `gcc` (`6.2.0 20161005 (Ubuntu 6.2.0-5ubuntu12)`) produces the following output from `/usr/bin/file program`:

    program: 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]=signature_here, not stripped

The program is also identified as a "shared library" instead of an "executable" in Thunar, causing it to not be runnable from the GUI. Others are unable to run such programs from Nautilus.

/usr/bin/ls: 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.0.0, BuildID[sha1]=339279bdac0d1a8c98b6bbb92afc8d8edb185d9f, stripped

This file is detected as application/x-sharedlib instead of application/x-executable, by the s-m-i test suite, if I add it there.

Patch for the test suite: http://www.davidfaure.fr/kde/smi.diff
+ downloading http://www.davidfaure.fr/kde/ls into tests/.

Result:
ls, 'data' test: expected application/x-executable, got application/x-sharedlib
ls, 'file' test: expected application/x-executable, got application/x-sharedlib

There must be a bug in the ELF magic for application/x-sharedlib and/or application/x-executable.

Or you could just dump the file into the staging-tests/ directory, and run "make local-test". Patch welcome, but I wonder how useful that magic (or lack of accuracy) actually is.

Well we need a way to find out that /bin/ls is an executable, and there's no extension, so working magic would be useful ;)

However I don't know anything about the ELF file format, so I don't know what the problem actually is (and whether it offers reliable magic).

Admittedly the magic for x-sharedlib is the one that's much less useful, shared libs are typically called *.so or *.so.[0-9\.]* :-)
But I wouldn't dare just removing all magic from x-sharedlib... unless someone can prove that the ELF file format makes no actual difference between shared libs and executables?

Olathe (erlercw+launchpad) wrote :

Note that the automatically added information is for 16.04 rather than where the bug occurs, on 16.10.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gcc-defaults (Ubuntu):
status: New → Confirmed

I have removed all the wrong automatic info.

tags: added: yakkety
removed: xenial
description: updated
Changed in gcc-defaults (Ubuntu):
importance: Undecided → Critical
importance: Critical → High
status: Confirmed → Triaged

The ELF file format distinguishes between traditional executables and shared
objects, but unfortunately PIE executables are treated as ELF shared objects

AFAIK, a shared object could be a PIE program if it has a (valid) interpretor header (PT_INTERP).

It should be noted that glibc's ELF loader (ld-linux.so, exact name depending on architecture) is a shared object and a valid program, but doesn't have an interpretor header, but that's the only exception I aware of.

IOTH, glibc's libc.so is a shared object with a valid interpretor, making it a valid program (try it !). Reporting such library as a program might be misleading for end user.

Anyway, PT_INTERP header not at a fixed location in the ELF file, so it cannot be described in shared-mime-info database.

(It's a pity PIE ELF files were not describe with a new ELF type or at least a flag :(

Changed in gcc-defaults:
importance: Unknown → Medium
status: Unknown → Confirmed
Changed in gcc-defaults:
status: Confirmed → Unknown
Matthias Klose (doko) on 2017-08-21
affects: gcc-defaults (Ubuntu) → shared-mime-info (Ubuntu)
Changed in shared-mime-info:
importance: Unknown → Medium
status: Unknown → Confirmed

This has been open for over a year, and is related to even older bugs in tools that depend on shared-mime-info (e.g. https://bugzilla.gnome.org/show_bug.cgi?id=737849 ). This is also an issue in libmagic, and there is more discussion about ELF over there: https://bugzilla.redhat.com/show_bug.cgi?id=1296868

It'd be great to have some sort of resolution here.

(In reply to Daniel Kahn Gillmor from comment #5)
> It'd be great to have some sort of resolution here.

That's not going to happen unless somebody has a patch. Reading comment 4, that seems unlikely. If you have applications that require this deep level of knowledge of the different formats, you'll probably want to use something more precise than the shared-mime spec.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xdg/shared-mime-info/issues/11.

Changed in shared-mime-info:
status: Confirmed → Unknown
peregrine (andrej1741) wrote :

18.04 bug still not fixed

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.