current directory not changed by -R

[fluxer]

Oddly, when proot is invoked with -R the current directory is not actually changed to the cpecified new root directory leaving the shell in the current directory with access outside of the new root. This does not happend with invoked with -r. Here is an exmaple:

pwd
/home/smil3y/Desktop/builder
./proot-x86 -R kde_root_i686/ -0
pwd
/home/smil3y/Desktop/builder

pwd
/home/smil3y/Desktop/builder
./proot-x86 -r kde_root_i686/ -0
proot warning: can't chdir("/home/smil3y/Desktop/builder/./.") in the guest rootfs: No such file or directory
proot info: default working directory is now "/"
pwd
/

That looks like a critical issue and I expect it not to happen, or is there a reasonfor doing so?

[cedric-vincent]

Hello @fluxer,

By default, PRoot changes the [guest] current working directory to $PWD (ie. same as the host one). This is useful when launching programs in the guest rootfs using a relative path ("./configure" is a typical example). Of course this assumes that $PWD is bound/mounted into the the guest rootfs, hence the following warning when it's not the case:

proot warning: can't chdir("[...]") in the guest rootfs: No such file or directory
proot info: default working directory is now "/"

Regarding the -R option, it is similar to the -r option but it also binds/mounts a couple of "useful" directories into the guest rootfs. In your example, one of this "useful" directory ($HOME) is a parent of $PWD:

$ pwd
/home/smil3y/Desktop/builder

As a consequence, the "chdir($PWD)" performed by PRoot into the guest rootfs succeed. This is expected (remember the "./configure" example).

Now if you move to -- let's say -- "/etc" before running PRoot, you'll be in the "/etc" directory from the guest rootfs (I agree that could be confusing):

$ cd /etc
$ cat slackware-version 
Slackware 14.1

$ proot -R ~/rootfs/gentoo-amd64-hardened+nomultilib/
$ cat slackware-version 
/bin/cat: slackware-version: No such file or directory

$ cat gentoo-release 
Gentoo Base System release 2.2

Another example, if you move to a directory that exists into the host rootfs but that doesn't exist into the guest rootfs, you'll get the expected warning:

$ cd /usr/x86_64-slackware-linux/
$ proot -R ~/rootfs/gentoo-amd64-hardened+nomultilib/
proot warning: can't chdir("/usr/x86_64-slackware-linux/./.") in the guest rootfs: No such file or directory
proot info: default working directory is now "/"

If you don't want your $HOME bound/mounted into the guest rootfs, either use the -r option with explicit -b options:

$ proot -r guest-rootfs/      \
        -b /etc/host.conf     \
        -b /etc/hosts         \
        -b /etc/hosts.equiv   \
        -b /etc/mtab          \
        -b /etc/netgroup      \
        -b /etc/networks      \
        -b /etc/passwd        \
        -b /etc/group         \
        -b /etc/nsswitch.conf \
        -b /etc/resolv.conf   \
        -b /etc/localtime     \
        -b /dev/              \
        -b /sys/              \
        -b /proc/             \

or use the -R option, then (order matters) bound/mount an empty directory over $HOME:

$ mkdir empty
$ proot -R guest-rootfs -b empty:/home/smil3y/

Please, let me know if you think we can make this default behavior less confusing.

Regards, Cédric.

[fluxer]

I understand your point but I must say I didn't expected that. Usually, chroot changes working directory to the root (/) right after changing root to the guest filesystem

I'm familiar with the -b option, I've used it in certain cases. It certainly has it's purpose. Just now I noticed that there is a -w (and certian alternative) options that may do what I'm looking for (e.g. proot -w / -R new_root) but again, I find it confusing compared to the chroot, provided by coreutils or busybox, behavior and would like to see this behavior corrected. If not, then at least there is a way to make proot behave as I expect so it's better than nothing.

And by the way, -b empty:/home/smil3y/ seems neat :).

Cheers, Ivailo.