No PIE for you!

You are a software vendor. You distribute software on multiple operating systems. Let’s say your software is a mildly popular internet browser. Let’s say its logo represents an animal and a globe.

Now, because you care about the security of your users, let’s say you would like the entire address space of your application to be randomized, including the main executable portion of it. That would be neat, wouldn’t it? And there’s even a feature for that: Position independent executables.

You get that working on (almost) all the operating systems you distribute software on. Great.

Then a Gnome user (or an Ubuntu user, for that matter) comes, and tells you they downloaded your software tarball, unpacked it, and tried opening your software, but all they get is a dialog telling them:

Could not display “application-name” There is no application installed for “shared library” files

Because, you see, a Position independent executable, in ELF terms, is actually a (position independent) shared library that happens to be executable, instead of being an executable that happens to be position independent.

And nautilus (the file manager in Gnome and Ubuntu’s Unity) usefully knows to distinguish between executables and shared libraries. And will happily refuse to execute shared libraries, even when they have the file-system-level executable bit set.

You’d think you can get around this by using a .desktop file, but the Exec field in those files requires a full path. (No, ./ doesn’t work unless the executable is in the nautilus process current working directory, as in, the path nautilus was run from)

Dear lazyweb, please prove me wrong and tell me there’s a way around this.

2014-10-03 18:00:03+0900

p.d.o, p.m.o

You can leave a response, or trackback from your own site.

8 Responses to “No PIE for you!”

  1. Elessar Says:

    I think there would be an easy work around: shell wrapper. A shell wrapper that users (that is, users of the precompiled package, not users of distro packages which would not need that) would launch instead of the binary itself, and that would first locate itself (dirname “$(realpath “$0″)” I guess), and then launch the binary it will find at its side.

  2. Bryan Quigley Says:

    Is that why my Firefox nightly stopped working? Did PIE just get turned on for Linux?

  3. glandium Says:

    Bryan: yep. And it’s going to be off in next nightly. Note you can still start it from e.g. the command line.

    Elessar: iirc from the time when Firefox did have a shell wrapper, that comes with other problems.

  4. pdw Says:

    So, could you have a binary wrapper? All it would have to do is execv(“/proc/self/cwd/real-firefox”, argv).

  5. Anonymous Says:

    Have you already reported an (important-severity) bug on nautilus?

  6. glandium Says:

    Anonymous: of course (although I didn’t set any importance level)

  7. Ed Morley Says:

    For those looking for the filed bug, it’s at

  8. afunix Says:

    Does it work in Fedora? In Red Hat world?

Leave a Reply