Allow users to specify that they don't want symlink target path expansion

[copumpkin]

trafficstars

Traditional (non-fake) chroot invocations will not touch symlink targets, instead treating them like opaque strings. This commit lets users ask for that behavior from fakechroot as well.

cc @dex4er

[tripzero]

I've verified this on my system.

[copumpkin]

Thanks @tripzero

@dex4er I'm sort of torn: I think defaulting to the symlink behavior I added in this commit is actually more true to the original chroot behavior, but it is also a change in semantics and I'm reluctant to add a silent change like that to a project that many people use. Do you have any input on that?

[TSonono]

@josch Any chance this could be included the debian set of patches for fakechroot? I think this makes sense if you for instance want to make a rootfs with debootstrap in a rootless manner (--variant==fakechroot). More justification in #45, https://github.com/dex4er/fakechroot/issues/45#issuecomment-282424879

[josch]

@josch Any chance this could be included the debian set of patches for fakechroot? I think this makes sense if you for instance want to make a rootfs with debootstrap in a rootless manner (--variant==fakechroot). More justification in #45, #45 (comment)

So far I've only patched things that fixed bugs and have not introduced new functionality for fakechroot in Debian. If I also add new functionality, that would make fakechroot in Debian even more of a real fork than it already is. I would very much prefer if somebody would commit to maintaining fakechroot so that I don't have to.

Other than that, I think the proposed change is mostly harmless as it does not change default behaviour. I'm surprised though that people first want to build a chroot using fakechroot and then use real chroot to enter it afterwards. What is the point of using fakechroot if apparently you have the necessary privileges to call chroot? And even then, the ownership information in that chroot will be all wrong. I'm interested in why this usecase is useful to people.

[TSonono]

@josch Any chance this could be included the debian set of patches for fakechroot? I think this makes sense if you for instance want to make a rootfs with debootstrap in a rootless manner (--variant==fakechroot). More justification in #45, #45 (comment)

So far I've only patched things that fixed bugs and have not introduced new functionality for fakechroot in Debian. If I also add new functionality, that would make fakechroot in Debian even more of a real fork than it already is. I would very much prefer if somebody would commit to maintaining fakechroot so that I don't have to.

Other than that, I think the proposed change is mostly harmless as it does not change default behaviour. I'm surprised though that people first want to build a chroot using fakechroot and then use real chroot to enter it afterwards. What is the point of using fakechroot if apparently you have the necessary privileges to call chroot? And even then, the ownership information in that chroot will be all wrong. I'm interested in why this usecase is useful to people.

I can't speak for the last use case you mention. But having a rootless ownership root file system can be nice if you want to run applications that utilize that file system without having to run as root. That could for example be with when using QEMU along with the virtiofsd daemon. Say you have created a root file system with fakechroot fakeroot debootstrap --variant=fakechroot .... You might want to access that root file system without having to run virtiofsd under sudo, which would be why you would use the fakechroot variant.

Without this change, the symlink paths (for example /sbin/init) in the root file system when using --variant=fakechroot would expand to paths outside of the directory that contains the root file system, rendering an incorrect root file system for use cases similar to the aforementioned example