fake_id0: do not re-translate the chroot path

[lightful]

The call to chroot "/" from UID 0 may fail with "No such file or directory". This call is invoked e.g. by pacman during the post-install.

The culprit is this commit, which added extra calls to translate_path and realpath. These are unnecessary because the function handling chroot, which is invoked from SYSCALL_EXIT_END, already receives the path translated (during the enter syscall, translate_sysarg() ultimately invokes translate_path() and stores it via set_sysarg_path()). The mentioned commit even tries to translate the path returned by get_root(tracee). It was trying to solve some issue which in the end was not solved, as the latest posts in that thread acknowledge.

The duplicated translation try may accidentally be harmless but may cause errors depending on the bindings configuration. I think that this may have not been reported until now because many distros choose to bind paths in /data, usually within the guest root filesystem. When that is not the case (e.g. a "pure" Linux root directory emulation) the substitute_binding() step during the translation fails and ruins the chroot.

I revert here to the original implementation (which of course already supported relative paths).

[lightful]

The simplest way to reproduce the issue is to run proot without any bindings:

(Moto G):~$ proot -i 0:0 -r /data/data/com.termux/files/proot/arch/ -w / /usr/bin/env -i /usr/bin/bash -l
[root@localhost /]# chroot /
chroot: cannot change root directory to '/': No such file or directory

[lightful]

Well, I see that the original code was also not perfect, because was comparing the non-canonicalized chroot path. The original PR (I just have find it) tried to fix chroot "." errors. And this step is indeed necessary with relative paths:

(chroot "." from root directory):
e.g. get_root(tracee)  vs  non_canonicalized_path
[/data/data/com.termux/files/proot/arch] vs [/data/data/com.termux/files/proot/arch/.]

I have added a second commit. Now not only chroot "/" but also "." (from /) works!

The canonicalization could maybe be systematically performed at translate_path2() in enter.c, perhaps? You'll know better.

[michalbednarski]

Thanks, looks nice