Hi Florian,
On Sat, Dec 04, 2021 at 01:59:14PM +0100, Florian Weimer wrote:
> It is as architecture-independent as ldconfig or getconf. Perhaps a bit
> more so than getconf.
Both of those are bad examples as both are lies. An amd64 ldconfig
really does not handle arm64 libraries at all. I'd rath
* Aurelien Jarno:
> Hi,
>
> On 2021-12-02 19:51, Florian Weimer wrote:
>> I'd like to provide an ld.so command as part of glibc. Today, ld.so can
>> be used to activate preloading, for example. Compared to LD_PRELOAD,
>> the difference is that it's specific to one process, and won't be
>> inheri
Hi,
On 2021-12-02 19:51, Florian Weimer wrote:
> I'd like to provide an ld.so command as part of glibc. Today, ld.so can
> be used to activate preloading, for example. Compared to LD_PRELOAD,
> the difference is that it's specific to one process, and won't be
> inherited by subprocesses—somethin
* Helmut Grohne:
> Hi Florian,
>
> On Fri, Dec 03, 2021 at 06:29:33PM +0100, Florian Weimer wrote:
>> We can add a generic ELF parser to that ld.so and use PT_INTERP, as I
>> mentioned below. I think this is the way to go. Some care will be
>> needed to avoid endless loops, but that should be it
Hi Florian,
On Fri, Dec 03, 2021 at 06:29:33PM +0100, Florian Weimer wrote:
> We can add a generic ELF parser to that ld.so and use PT_INTERP, as I
> mentioned below. I think this is the way to go. Some care will be
> needed to avoid endless loops, but that should be it.
Can I ask you to go int
On Fri, Dec 03, 2021 at 05:59:17PM +0100, Florian Weimer wrote:
> * Theodore Y. Ts'o:
>
> > * How does ld.so --preload *work*?
>
> The dynamic loader has an array of preloaded sonames, and it processes
> them before loading the dependencies of the main program. This way,
> definitions in the pre
On Fri, 03 Dec 2021 at 18:29:33 +0100, Florian Weimer wrote:
> > On Thu, 02 Dec 2021 at 19:51:16 +0100, Florian Weimer wrote:
> >> If someone wants to upstream the multi-arch patches, that would be
> >> great.
> >
> > I think multiarch is mostly build-time configuration rather than patches.
>
> We
* Simon McVittie:
> On Thu, 02 Dec 2021 at 19:51:16 +0100, Florian Weimer wrote:
>> Having ld.so as a real command makes the name architecture-agnostic.
>> This discourages from hard-coding non-portable paths such as
>> /lib64/ld-linux-x86-64.so.2 or even (the non-ABI-compliant)
>> /lib/x86_64-lin
On Fri, Dec 03, 2021 at 11:33:25AM -0500, Theodore Y. Ts'o wrote:
> Some stupid questions that I couldn't answer by reading the man page
> or doing a quick google search
> * How does ld.so --preload *work*?
ld.so is the ELF interpreter. If you run a normal binary, the kernel
rewrites this req
On Fri, Dec 03, 2021 at 04:16:04PM +0200, Timo Lindfors wrote:
> Just a random thought: If you have configured a restricted shell (e.g.
> rbash) that only lets you execute commands in PATH, will this make it
> possible to bypass the restriction with "ld.so /tmp/some-random-binary"?
> This is not ne
* Theodore Y. Ts'o:
> * How does ld.so --preload *work*?
The dynamic loader has an array of preloaded sonames, and it processes
them before loading the dependencies of the main program. This way,
definitions in the preloaded objects preempt definitions in the shared
objects.
> * Does it modify
On Thu, 02 Dec 2021 at 19:51:16 +0100, Florian Weimer wrote:
> Having ld.so as a real command makes the name architecture-agnostic.
> This discourages from hard-coding non-portable paths such as
> /lib64/ld-linux-x86-64.so.2 or even (the non-ABI-compliant)
> /lib/x86_64-linux-gnu/ld-linux-x86-64.so
On Fri, Dec 03, 2021 at 02:46:27PM +0100, Bastian Blank wrote:
> On Fri, Dec 03, 2021 at 01:57:08PM +0100, Florian Weimer wrote:
> > Right, thanks for providing a concrete example. A (somewhat) portable
> > version would look like this:
> > ld.so --preload '/usr/$LIB/libeatmydata.so.1.3.0' /bin/
Hi,
On Fri, 3 Dec 2021, Florian Weimer wrote:
No objects to /usr/bin/ld.so then?
Just a random thought: If you have configured a restricted shell (e.g.
rbash) that only lets you execute commands in PATH, will this make it
possible to bypass the restriction with "ld.so /tmp/some-random-binary
* Bastian Blank:
> On Fri, Dec 03, 2021 at 01:57:08PM +0100, Florian Weimer wrote:
>> Right, thanks for providing a concrete example. A (somewhat) portable
>> version would look like this:
>> ld.so --preload '/usr/$LIB/libeatmydata.so.1.3.0' /bin/sl
>
> You mean
> ld.so --preload libeatmydata
On Fri, Dec 03, 2021 at 01:57:08PM +0100, Florian Weimer wrote:
> Right, thanks for providing a concrete example. A (somewhat) portable
> version would look like this:
> ld.so --preload '/usr/$LIB/libeatmydata.so.1.3.0' /bin/sl
You mean
ld.so --preload libeatmydata.so.1.3.0 /bin/ls
?
ld.so i
* Paul Wise:
> Florian Weimer wrote:
>
>> I'd like to provide an ld.so command as part of glibc.
>
> Will this happen in glibc upstream or just in Debian?
Upstream, and then Debian. The symbolic link would likely and up in
libc-bin in Debian.
>> Today, ld.so can be used to activate preloading,
Florian Weimer wrote:
> I'd like to provide an ld.so command as part of glibc.
Will this happen in glibc upstream or just in Debian?
> Today, ld.so can be used to activate preloading, for example.
> Compared to LD_PRELOAD, the difference is that it's specific to one
> process, and won't be inhe
18 matches
Mail list logo
