mailing list of musl libc
 help / color / mirror / code / Atom feed
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).


  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).