Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 6 Apr 2014 13:22:54 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Re: MUSL_LIBRARY_PATH ?

On Sun, Apr 06, 2014 at 06:17:47PM +0100, Laurent Bercot wrote:
> On 06/04/2014 17:18, Rich Felker wrote:
> >The obvious workaround is to put a shell script in place of your
> >actual binary, and have it do:
> >
> >   exec "$ldso" -- "foo.bin" "$@"
> >
> >or similar. Alternatively a minimal static-linked binary could be used
> >instead of shell script to make it perform better and eliminate some
> >of the risks of shell script processing.
> 
>  Shameless plug: this is the perfect use case for execline.
>  http://skarnet.org/software/execline/
>  An execline script will perform better here than a shell script, without
> the risks, and still offer the editability of a script.

Actually execline is not a solution for this, since the #! line that
invokes execline has to contain an absolute pathname to execline,
which is exactly the same problem we were trying to solve to begin
with: the need to install the program interpreter at a fixed absolute
pathname on a system you might not have root on.

This can be avoided by using /usr/bin/env if you're willing to trust
that the env command is at that location and and the user adds
execline to their PATH, but that's fragile and adds yet another level
of indirection at program exec time...

The idea of the minimal static-linked binary as a solution is that it
would not need a program interpreter (dynamic linker or #! type) but
instead could do its own search (e.g. relative to its own binary) for
the dynamic linker to invoke.

Rich

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.