From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4765 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: MUSL_LIBRARY_PATH ? Date: Tue, 1 Apr 2014 12:40:51 -0400 Message-ID: <20140401164051.GA7953@brightrain.aerifal.cx> References: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1396370472 21728 80.91.229.3 (1 Apr 2014 16:41:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 1 Apr 2014 16:41:12 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4769-gllmg-musl=m.gmane.org@lists.openwall.com Tue Apr 01 18:41:08 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1WV1kJ-0003mq-Fp for gllmg-musl@plane.gmane.org; Tue, 01 Apr 2014 18:41:07 +0200 Original-Received: (qmail 3575 invoked by uid 550); 1 Apr 2014 16:41:06 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 3560 invoked from network); 1 Apr 2014 16:41:06 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:4765 Archived-At: 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