From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4723 Path: news.gmane.org!not-for-mail From: orc Newsgroups: gmane.linux.lib.musl.general Subject: Re: be able to break inheritance of LD_LIBRARY_PATH Date: Fri, 28 Mar 2014 20:18:28 +0800 Message-ID: <60c9e4b3-184e-4fae-9160-e83d1bb643a7@email.android.com> References: <20140328104208.GZ8221@example.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1396009180 6978 80.91.229.3 (28 Mar 2014 12:19:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 28 Mar 2014 12:19:40 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4727-gllmg-musl=m.gmane.org@lists.openwall.com Fri Mar 28 13:19:50 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 1WTVlB-0000qD-Jn for gllmg-musl@plane.gmane.org; Fri, 28 Mar 2014 13:19:45 +0100 Original-Received: (qmail 20322 invoked by uid 550); 28 Mar 2014 12:19:44 -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 20314 invoked from network); 28 Mar 2014 12:19:44 -0000 User-Agent: K-9 Mail for Android In-Reply-To: <20140328104208.GZ8221@example.net> Xref: news.gmane.org gmane.linux.lib.musl.general:4723 Archived-At: 28 марта 2014 г. 18:42:08 KRAT, u-igbb@aetey.se пишет: >Hello, > >I was aware of musl for some time and now consider deploying it as >a default library for new software builds, due to its very appealing >virtues. > >Yet there is a small but important issue. > >For our software setup it is crucial (quite useful otherwise in >general) >to be able to specify the location of the dynamic libraries per >binary/run >_without_ the unconditional inheritance imposed by LD_LIBRARY_PATH. > >A very nice solution would be the ability to explicitely run a >standalone >dynamic loader, as implemented in both glibc and uclibc. We are heavily >relying on this functionality. > >I do not know how hard it would be to teach the musl loader >to be runnable standalone and which corner cases this might create. > >As a simpler approach I might suggest simply being able to drop >LD_LIBRARY_PATH as soon as it has been read. An extra environment >variable as a flag would do. > >Compared to a standalone loader this lacks the ability to run >a binary with a different version of the loader/musl but at least >makes it straightforward and safe to freely specify where to find other >libraries. > >A naïve implementation might look as follows: > >--- src/ldso/dynlink.c.ori 2014-03-28 10:37:34.821317811 +0100 >+++ src/ldso/dynlink.c 2014-03-28 11:21:16.828047766 +0100 >@@ -962,6 +962,7 @@ > size_t vdso_base; > size_t *auxv; > char **envp = argv+argc+1; >+ int forget_ld_library_path = 0; > > /* Find aux vector just past environ[] */ > for (i=argc+1; argv[i]; i++) >@@ -969,8 +970,19 @@ > env_path = argv[i]+16; > else if (!memcmp(argv[i], "LD_PRELOAD=", 11)) > env_preload = argv[i]+11; >+ else if (!memcmp(argv[i], "FORGET_LD_LIBRARY_PATH=", >23)) >+ forget_ld_library_path = 1; > auxv = (void *)(argv+i+1); > >+ /* one _may_ wish to break the inheritance of LD_LIBRARY_PATH, >+ * the hack below only works if the corresponding memory is >writable >+ * -- rl */ >+ if (forget_ld_library_path) >+ for (i=argc+1; argv[i]; i++) >+ if (!memcmp(argv[i], "LD_LIBRARY_PATH=", 16) || >+ !memcmp(argv[i], "FORGET_LD_LIBRARY_PATH=", >23)) >+ argv[i][0] = 'X'; >+ > decode_vec(auxv, aux, AUX_CNT); > > /* Only trust user/env if kernel says we're not suid/sgid */ > > >What do you think about this? Can this or something better be done? >I would love to be able to go with musl. > >Regards, >Rune Such change should be maintained locally by you probably. While LD_PRELOAD/LD_LIBRARY_PATH environment variables are "standard" enough (widely known), introduction of extra variables that control various aspects of dynamic linker internals is becoming a pain, especially for people writing security related software. For example, I already maintain such a local change that introduces LD_NORPATH (disables reading DT_RPATHs from executable, and forces it for all setuids).