Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <5341B89E.6060800@skarnet.org>
Date: Sun, 06 Apr 2014 21:27:10 +0100
From: Laurent Bercot <ska-dietlibc@...rnet.org>
To: musl@...ts.openwall.com
Subject: Re: Re: MUSL_LIBRARY_PATH ?

On 06/04/2014 18:22, Rich Felker wrote:
> 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.

  That will of course change when execline has conquered the world and
is installed by every administrator at a standardized location. You're
not helping me much with that goal here. :)


> 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...

  Yes, even /bin/sh is probably better than /usr/bin/env + another
indirection.


> 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.

  It's certainly the most efficient solution for any given binary, but
it's less scalable - as in easy to maintain - than a script-based solution.

-- 
  Laurent

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.