Files Are Compiled As Shared Libraries Instead Of Executables

[he's dead jim]

I have researched this problem and apparently as of debian stretch, the pie function which was previously default off has been made default on.

not sure what that means as i am only a novice when it come to coding but the answer seems to be to use the following when compiling:

gcc main.c -o main -no-pie

the problem is, none of the many threads that i searched actually showed me how to use this, or where to use this. for example. when i am in the source directory, most of the time i have to just use:

qmake
make

with the particular source that i am trying to compile right now, i use:

./autogen.sh
./configure --with-incompatible-bdb --with-boost-libdir=/usr/lib/i386-linux-gnu
make

how and where do i put that gcc line in to make it work?

thanks

[scruss]

What are you trying to build? Boost applications can be a bit of a pain, but usually installing libboost-all-dev fixes that:

Code: Select all

sudo apt install libboost-all-dev

It would help a lot to know what package you're trying to build.

[he's dead jim]

it has nothing to do with boost or any particular file. i seems to be anything that i build.

sorry i forgot to say that pie stands for position-independent executable (PIE)

it is now turned on by default as of debian stretch.

if i compile the same source in debian jessie the source compiles just fine into an executable like it should.

just found this explanation for ubuntu but it's the same in debian stretch:

------------------------------------------------------------------------------------------------------------------------------------------------------------------

I have fixed this behavior by adding the following line on my project's .pro file in QT:

QMAKE_LFLAGS += -no-pie

The behavior is occurring because newer ubuntu distros set GCC default link flag -pie, which marks e_type as ET_DYN on the binary file. Consequently, the Operating System recognizes as Shared Library.

To work around it, it may be necessary to add -no-pie on compiler option.

------------------------------------------------------------------------------------------------------------------------------------------------------------------

i'm gonna try editing the pro file and see if it compiles

[he's dead jim]

tried a few compiles and didn't work.

gonna go back to jessie for now. if anyone finds a solution please post it in this thread.

this problem is common across many versions of linux including ubuntu, debian, arch and raspbian, all starting with stretch.

jessie does not have this problem.

[jojopi]

The behavior is occurring because newer ubuntu distros set GCC default link flag -pie, which marks e_type as ET_DYN on the binary file. Consequently, the Operating System recognizes as Shared Library.

You have not explained how this matters.

Yes the compiler makes position independent executables by default, and the ELF headers say that such binaries are shared objects rather than executables. They still execute perfectly fine though. Most of the system binaries are built the same way.

[he's dead jim]

The behavior is occurring because newer ubuntu distros set GCC default link flag -pie, which marks e_type as ET_DYN on the binary file. Consequently, the Operating System recognizes as Shared Library.

You have not explained how this matters.

Yes the compiler makes position independent executables by default, and the ELF headers say that such binaries are shared objects rather than executables. They still execute perfectly fine though. Most of the system binaries are built the same way.

yes but when i try to execute the file i just get a pop-up asking to choose an application to open this file type with.

what do i choose?

how do i make it an executable?

any monkey can compile. it's just a few commands once you download the source.

most errors can be googled. in the end, i'm still just a user who doesn't know an ELF header from adam lol.

[scruss]

Works fine here on a VirtualBox installation of the RP Desktop:

simple c build

Screenshot from 2018-02-05 23-18-01.png (48.29 KiB) Viewed 4176 times

But you're right, if you use the file manager to launch files, it shows up as "shared library" and won't run.

I guess no-one uses the file manager, then …

[he's dead jim]

Thanks.

I appreciate you trying and confirming it. Unfortunately the stuff that i compile relies on being executed with a double click from the icon on the desktop.

I looked at the properties of the existing icons but I can't find anything helpful.

If I knew what to associate the icon with i'd be in business.

[ghans]

Shortcuts on freedesktop.org compatible desktops are text files.

https://wiki.archlinux.org/index.php/desktop_entries

ghans

[he's dead jim]

I have confirmed that this does work:

------------------------------------------------------------------------------------------------------------------------------
I have fixed this behavior by adding the following line on my project's .pro file in QT:

QMAKE_LFLAGS += -no-pie
------------------------------------------------------------------------------------------------------------------------------

however, in my opinion ther should be a better way to do this.

there are gonna be a lot of cross compatibility issues between jessie and stretch for the people i compile for.

i'm talking hundreds of source files.

[PhilE]

Let's start from the basics: build a program with and without the -no-pie flag and post the output of "file <progname>" (where <progname> is the name of the executable) for both versions.

[scruss]

Let's start from the basics: build a program with and without the -no-pie flag and post the output of "file <progname>" (where <progname> is the name of the executable) for both versions.

file alone doesn't catch it, Phil. This bug also affects x86_64, and I've just dropped a bug on Ubuntu about this. Here's my bug summary - please excuse x86_64, I assure you it's present on Raspberry Pi Desktop 32-bit/x86:

Code: Select all

Expected 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-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:

    $ 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 (Position Independent Executable) enabled on x86 Debian systems for security reasons. So it's likely an upstream bug in file that's preventing PCManFM from correctly running executables. This doesn't seem to affect ARM.

he's dead jim: while compiling with -no-pie is a short-term workaround, it may also be a security risk for your users.

[PhilE]

Including hard information makes it so much easier to Google stackoverflow: https://stackoverflow.com/questions/413 ... -applicati

[he's dead jim]

he's dead jim: while compiling with -no-pie is a short-term workaround, it may also be a security risk for your users.

yep thanks

i just wanted to see if it did work as advertised.

i'd much rather find a way for it to work with pie enabled as extra security is never a bad thing.

[n67]

Two questions:

1) Why is compiling with -pie more "secure" ?
Note: I am quite familiar with -pie and what it does; I use it when I want to compile a program in such a way that a single file will function as either an executable or a shared library.

2) Why is your version of "file" displaying "shared object" when you are compiling it as a straight up executable? Normally, file displays something like "LSB executable" for executables. See below:

Code: Select all

$ file /bin/ls
/bin/ls: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.32, BuildID[sha1]=5e052e8de057d379ab51d4af510ad9318fe77b46, stripped
$ file /lib/libnih.so.1.0.0 
/lib/libnih.so.1.0.0: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=46a359631e3df17e1d934ed02d4a4651f3c52921, stripped

[scruss]

1) Why is compiling with -pie more "secure" ?

It apparently allows Address space layout randomization (ASLR), which is supposed to make it harder to guess where a process's stack and other squishy bits are in memory.

2) Why is your version of "file" displaying "shared object" when you are compiling it as a straight up executable? Normally, file displays something like "LSB executable" for executables.

Depends on the platform. Under Raspbian, I get "ELF 32-bit LSB executable". On x86 and Beaglebone (Debian 9), I get "ELF __-bit LSB shared object" for PIE executables, and "ELF __-bit LSB executable," for no-pie ones.

[PhilE]

My findings are slightly different, but I agree that Position Independent Executables confuse the mimetype mechanism.

In the most recent Raspbian Stretch image (Nov 29th 2017) gcc generates normal position-dependent code by default, but I can believe that somewhere the default has changed. Adding '-pie' to the GCC creates the position-independent version.

In this output, pdfoo is the normal position-dependent elf, and pifoo is position-independent:

Code: Select all

[email protected]:~ $ file pdfoo
pdfoo: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=4595b7b91b4664bb34eea3a09fb3b27af4c0596a, not stripped
[email protected]:~ $ file -i pdfoo
pdfoo: application/x-executable; charset=binary
[email protected]:~ $ hexdump pdfoo | head -2
0000000 457f 464c 0101 0001 0000 0000 0000 0000
0000010 0002 0028 0001 0000 02e0 0001 0034 0000

[email protected]:~ $ file pifoo
pifoo: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=3c6fe8043dec1156c0b9b85e73ce48635e4f1cca, not stripped
[email protected]:~ $ file -i pifoo
pifoo: application/x-sharedlib; charset=binary
[email protected]:~ $ hexdump pifoo | head -2
0000000 457f 464c 0101 0001 0000 0000 0000 0000
0000010 0003 0028 0001 0000 0468 0000 0034 0000

The "file" utility uses a file of magic numbers to identify file types. The following section of the source shows how the decision is made: [ From https://github.com/file/file/blob/a25f2 ... ir/elf#L44 ]

Code: Select all

0	name		elf-le
>16	leshort		0		no file type,
!:mime	application/octet-stream
>16	leshort		1		relocatable,
!:mime	application/x-object
>16	leshort		2		executable,
!:mime	application/x-executable
>16	leshort		3		shared object,
!:mime	application/x-sharedlib
>16	leshort		4		core file
!:mime	application/x-coredump

According to my limited understanding the 16-bit little-endian value at offset 16 determines the ELF sub-type. As you can see in the hex dumps above, pdfoo has 2 (executable) while pifoo has 3 (shared object).

The takeaway from this seems to be that while position-independent code may be better from a security perspective, the current implementation is a hack that confuses "file".

[scruss]

It turns out that the original developer of file is local to me and I've met him a few times. I'm getting contact details for the current maintainer soon, I hope.

Update: they've decided to fix it, but I don't know how long before this change will flow through to user distributions.

[he's dead jim]

It turns out that the original developer of file is local to me and I've met him a few times. I'm getting contact details for the current maintainer soon, I hope.

Update: they've decided to fix it, but I don't know how long before this change will flow through to user distributions.

Thanks.

That's awesome. I really appreciated it and I'm surre a great many others will as well.