|
Message-ID: <20150115155638.GB14316@example.net> Date: Thu, 15 Jan 2015 16:56:38 +0100 From: u-wsnj@...ey.se To: musl@...ts.openwall.com Subject: OT: Re: dynamic linking (Re: musl and android) Actually I do not suggest any change, musl suits my usage model well (kudos for the support of running the loader explicitly)! On Thu, Jan 15, 2015 at 08:34:45AM -0500, Rich Felker wrote: > That's why I said i depends on your perspective. From your perspective > this does not work. From most traditional distributions' perspectives, > it does. Well said. The traditional distributions choose to live with the far reaching consequences of their technical choices. I argue that some constraints (iow sacrifices) are not necessary and only exist as a consequence of the unfortunate choices. > > Unfortunately, no. $ORIGIN does not and can not replace a run time > > choice of the dynamic loader. > If you're distributing the binary and dynamic loader/libc and all > libraries it needs together, I'd assume they'd all be in the same > directory, or else in ../lib/ relative to the binary. In that case You suggest a somewhat more relaxed set of assumptions than the traditional ones. Yes this would be useful, but unfortunately still setting some more or less arbitrary boundaries. > $ORIGIN works perfectly fine. Note that $ORIGIN is _not_ an > environment variable; it's a dynamic-linker feature for locating > libraries relative to the ELF file (main executable or other library) > that needs (via DT_NEEDED) them, and the same concept would work for > PT_INTERP. Indeed, good to point this out for a casual reader. Using an environment variable would be otherwise a quite general solution but I guess this would be very hard to convince the kernel developers to implement (presumably hardly possible to implement without redesigning the kernel security model). Regards, Rune
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.