From: orc <orc@sibserver.ru>
To: musl@lists.openwall.com
Subject: Re: be able to break inheritance of LD_LIBRARY_PATH
Date: Fri, 28 Mar 2014 20:18:28 +0800 [thread overview]
Message-ID: <60c9e4b3-184e-4fae-9160-e83d1bb643a7@email.android.com> (raw)
In-Reply-To: <20140328104208.GZ8221@example.net>
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).
next prev parent reply other threads:[~2014-03-28 12:18 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-28 10:42 u-igbb
2014-03-28 12:18 ` orc [this message]
2014-03-28 12:52 ` u-igbb
2014-03-28 12:27 ` Alexander Monakov
2014-03-28 13:04 ` u-igbb
2014-03-28 13:17 ` Szabolcs Nagy
2014-03-28 14:00 ` u-igbb
2014-03-28 15:25 ` Szabolcs Nagy
2014-03-28 15:34 ` Alexander Monakov
2014-03-28 16:02 ` PATCH (Re: [musl] be able to break inheritance of LD_LIBRARY_PATH) u-igbb
2014-03-28 16:34 ` be able to break inheritance of LD_LIBRARY_PATH Daniel Cegiełka
2014-03-28 17:50 ` u-igbb
2014-03-28 18:03 ` Daniel Cegiełka
2014-03-28 18:21 ` u-igbb
2014-03-28 19:46 ` Rich Felker
2014-03-28 21:07 ` u-igbb
2014-03-28 21:48 ` Rich Felker
2014-03-29 7:25 ` u-igbb
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=60c9e4b3-184e-4fae-9160-e83d1bb643a7@email.android.com \
--to=orc@sibserver.ru \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).