--- On Thu, 7/3/08, Shachar Shemesh <[EMAIL PROTECTED]> wrote:
> From: Shachar Shemesh <[EMAIL PROTECTED]>
> Subject: Re: Linux executable startup stack structure
> To: [EMAIL PROTECTED]
> Cc: "Fakeroot NG" <[EMAIL PROTECTED]>, "linux-il" <[email protected]>
> Date: Thursday, July 3, 2008, 10:46 AM
> Valery Reznic wrote:
> > P.S. And what do you need it for (except curiosity) ?
> >
> >
> It's going to be a somewhat long p.s. If you understood
> the problem I'm
> trying to solve, skip ahead to area marked "proposed
> solution" for how
> I'll be trying to solve it.
Curiosity part is (mostly) satisfied.
I think your proposed solution will work (no reason why not)
And if you change AT_ENTRY in the auxv you'll trick ld-linux to think
it was loaded as interpreter and not directly.
But why you need it and what good it will do ?
Interpreter use this information (interpreter/directly) to adjust argc/argv
that will be passed to main()
Valery
>
> Here's a piece of trivia for you. /lib/ld-linux.so and
> glibc go
> together. This is true in the sense that they are compiled
> from the same
> sources, but even more so, it is true in the sense that you
> cannot
> intermix versions of it. Take an old linux version's
> chroot you have,
> replace ld-linux there with a new version, and try
> chrooting into it.
> You will likely get something along the lines of the
> following error:
> > # /usr/sbin/chroot /srv/chroot/etch/
> > /bin/bash: relocation error: /lib/tls/libc.so.6:
> symbol
> > _dl_out_of_memory, version GLIBC_PRIVATE not defined
> in file
> > ld-linux.so.2 with link time reference
>
> I'm not sure whether it's glibc relying on ld-linux
> or the other way
> around (the first would, at least, make some kind of
> sense), but any way
> you turn it, things don't work.
>
> As far as I know, there are three approaches to emulating a
> chroot.
> There is "fakechroot", which uses LD_PRELOAD.
> This means it cannot
> override anything that ld-linux (a statically compiled
> library, for
> obvious reasons) do, which means that when you run
> "chroot
> /srv/chroot/etch/", both ld-linux and glibc (as well
> as any other
> library mentioned in the ELF header) gets loaded from the
> real root of
> the system, so no problem there (except the obvious one -
> that the
> chroot isn't much of one). The second approach is the
> one employed by
> user mode linux. It basically catches everything and
> everywhere, and
> replaces the entire tasks otherwise performed by the real
> kernel, and so
> no problem but a HUGE overhead.
>
> Fakeroot-ng goes the middle path. In concept it does what
> fakechroot
> does - intercept syscalls and either perform them
> differently, give
> bogus answers or emulate something. The main difference
> (well, the main
> core difference) is that fakeroot-ng uses ptrace rather
> than LD_PRELOAD,
> which means that statically compiled programs (as well as
> programs
> merely not linked with glibc, or linked with a different
> version etc..)
> are handled. There is just one problem: Since that is the
> case, when you
> run "chroot /srv/chroots/etch", you get a
> chrooted process (i.e. - a
> process that fakeroot-ng emulates all path calls for) that
> tries to load
> /lib/glibc (which fakeroot-ng redirects to
> /srv/chroots/etch/lib/glibc).
> The entity loading the interpreter, however, is the kernel,
> and that is
> not controlled by fakeroot-ng. The result is that the Etch
> glibc is run
> with Lenny's ld-linux, and you get the same error
> message as above.
>
> The proposed solution
>
> I can't say I have it firmly, or that I know it will
> work. This is just
> something I'm investigating. The idea is that we modify
> the execve
> syscall so that instead of running /bin/cat or
> /srv/chroots/etch/bin/cat, we run
> /srv/chroots/etch/lib/ld-linux.so.
> This will cause the kernel to set up the memory and process
> state in a
> way that is almost what we want to eventually happen. After
> a successful
> execve on a traced program, the debugger gets a signal with
> the program
> traced before it had a chance to execute a single
> instruction. We then
> manually load /srv/chroots/etch/bin/cat into the process
> state, and
> modify the runtime structures so that ld-linux will think
> it was started
> in interpreter mode rather than in direct mode. This will
> cause the
> right interpreter to be loaded, and everything should work.
>
> There are many steps to climb in this plan, of course, but
> the only one
> for which I was missing data was this - where ld-linux
> found out which
> interpreter is active, and what other data is in there that
> maybe needs
> to be processed. For example, I found out that auxv also
> stores the uid
> and euid, and I may wish to modify these (as I'm trying
> to fool the
> program into thinking it's running as root). Then
> again, things worked
> fine so far without it, and I only need to delve there if
> I'm doing a
> chroot, so I may not bother. We'll see.
>
> Hope that answered the curiosity part :-)
>
> Shachar
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
