On Wed, Nov 27, 2013 at 10:15:19PM +0100, Piotr Roszatycki wrote:
> 2012/10/24 Jonathan Nieder <jrnie...@gmail.com>:
> > Thanks. Indeed, ideally fakechroot's execve should look up the
> > interpreter filename from the ELF .interp section, map it according to
> > the faked chroot, and set argv[0]. The hard part is the ELF parsing.
>
> It doesn't work correctly:
>
> 1. The glibc dynamic loader can't change argv[0] to other value than
> the file name. It means that some apps are broken, ie. busybox. See
> https://sourceware.org/bugzilla/show_bug.cgi?id=16124
This means this particular avenue of replacing argv[0] isn't open, but
how do you claim busybox is broken without argv[0] being replaced? Your
proposed feature for the runtime linker would allow for argv[0] being
replaced, but not being able to replace argv[0] with the passed value
shouldn't break anything (and a quick check indicates busybox works just
fine without it). Being able to replace argv[0] would mean could get at
busybox's `ls` or `sh` personalities without having the requisite
symbolic links.
Each command implemented by busybox is accompanied by a symbolic link to
the busybox binary (/bin/ls -> busybox, /bin/sh -> busybox. /usr/bin/expr
-> /bin/busybox, et al).
Now, the weakness of my solution without replacing argv[0] is merely that
the executed program sees the full path, but busybox deals with this just
fine. Normally if I type `ls -l /` into a shell, the program will see as
its arguments: { "ls", "-l", "/" } without the capability the program
will instead see: { "/bin/ls", "-l", "/" }, mainly argv[0] has the full
path instead of just the filename. Any program that changes behavior
based on argv[0] *should* be striping everything up to the last '/', but
I wouldn't be surprised if some fail to do this (but busybox isn't one of
those).
I dislike that executed programs see something different than if they
were called normally, but this shouldn't effect anything. My biggest
concern is this uses additional space in the environment and *might*
cause issues if someone was right up against the limits (hello, xargs).
> 2. Using dynamic loader directly from command line is possible but the
> loader is less stable and coredumps sometimes.
>
> You can test it already, eg. calling
>
> FAKECHROOT_ELFLOADER=/lib64/ld-linux-x86-64.so.2
>
> from test directory of fakechroot source. You should expect that
> debootstrap environment can be created but calling debian/rules or
> even ./configure in such environment fails.
Hmm... Two explanations come up for this. Is the debootstrap
environment i386, or amd64? I'm unsure of whether the amd64 runtime
loader can handle loading i386 binaries (I *hope* it isn't a mixed
environment, but this could be a problem). Second, this may be an issue
of shell scripts. I wouldn't be surprised if both of these were issues.
Unfortunately this reads like an issue where you're going to have to look
at the file being executed and behave appropriately, at least shell
scripts are easy to handle.
> Perhaps there is another possibility: to change .interp section for
> every binary file in fake chroot environment: off-line or even
> on-the-fly. I think about similar to chrpath tool which can change
> another ELF section.
I suspect you're overthinking the problem. Thank you for taking on this
bug, for the right situations fakechroot is a very handy tool.
--
(\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/)
\BS ( | ehem+sig...@m5p.com PGP 87145445 | ) /
\_CS\ | _____ -O #include <stddisclaimer.h> O- _____ | / _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
