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.