[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140401164051.GA7953@brightrain.aerifal.cx>
Date: Tue, 1 Apr 2014 12:40:51 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: MUSL_LIBRARY_PATH ?
On Tue, Apr 01, 2014 at 10:11:57AM -0400, John Mudd wrote:
> Possible dumb question...
>
> I built Python using musl. Not easy but it works.
>
> I also build libraries for Ncurses, Readline, Zlib, OpenSSL, BZip2 so that
> all of that so the corresponding Python modules are working. Then I
> installed setuptools and pip in Python. Then I used pip to download and
> install several modules: Requests, ConcurrentLogHandlerand Psutil. All
> using musl.
>
> I experimented with dynamic and static binding for the musl lib. I lean
> toward dynamic because I may have a need for the "shared" version of Python.
Yes, Python is rather useless without dlopen...
> So now I can run this on older machines. That helps me because I need to
> deploy on old boxes. Upgrading the O/S is not an option.
>
> But I run into trouble when I start setting LD_LIBRARY_PATH so that Python
> can locate the Readline and other libs. The musl built Python works but
> these libs start causing native program to fail. e.g. "vim: error while
> loading shared libraries: /usr/lib/i386-linux-gnu/libc.so: invalid ELF
> header".
>
> And there's the ld-musl-i386.so.1 file in dynamic mode. I
> specified --syslibdir=/tmp when I build musl so that's where I place the
> lib. It works but I'd like more flexibility.
/tmp is a highly unsafe location. If between boot time and your
installation of this file, another user (possibly a compromised nobody
account, even) creates a file by the name name, you'll be tricked into
executing it. If you have root permissions on the box you should just
use the default --syslibdir; if not, use something under your own home
directory.
Note to self: Choosing a proper --syslibdir when you can't use the
default is a topic that should be covered in the manual, since it has
implications for security, moving binaries between systems, etc.
> I'm naive so my question is... how about a separate MUSL_LIBRARY_PATH shell
> variable. Just like LD_LIBRARY_PATH but specific to programs built using
> musl. That way I assume I could mix my musl Python with native apps.
>
> As long as I'm asking, can MUSL_LIBRARY_PATH also specify where to
> find ld-musl-i386.so.1? That might be crazy because a dynamic musl program
> can't start without the lib so it can't interrogate a shell variable? I'm
> still asking even though it might require magic.
I think you just need to have a path file, as described in the
documentation. For example if --syslibdir is /something/lib/, and your
dynamic linker is /something/lib/ld-musl-i386.so.1, then it will
search for its path file in /something/etc/ld-musl-i386.path.
LD_LIBRARY_PATH is really intended mainly for testing programs in the
build tree before installing them (note: libtool does this
automatically) rather than for configuring deployed programs.
As for adding new env vars, I'd prefer not to add any, and if they are
added, they MUST be in a well-known documented namespace. Adding
MUSL_LIBRARY_PATH would be a security problem because, even if it's
ignored for suid apps, such apps would have no way to knowing they
need to unset it to safely run an external program. If vars are to be
added, the need must be well-documented and alternative approaches
should have already been tried and exhausted.
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.
