Such tools are to allow an (ordinary) user to create a root environment within their little bubble WITHOUT affecting anyone else on the system. It all happens within their individual user space. They do NOT get any enhanced privileges.
As I say, within their little bubble only.
For example, they could install a software package within their own 'fake root' and the install routine would be lead to believe that it was installing on the main system but it's not.
To put it plainly, chroot is a real change root and not a fake change root and so it affects the whole system, i.e. all users. Therefore, it takes root privilege to action. The whole system is switched to running on a different root directory. Therefore, a standard user cannot be allowed to do this.
A fake chroot is playing around within a users own environment and nobody else sees any change.
An example of a real chroot can be when a system doesn't boot properly so the sysadmin boots the system from DVD into single user mode. Having booted that way, the system root is the root of the DVD. Now the sysadmin can use chroot to switch to the normal hard disk root to see how the system behaves; stable or wobbly?
I'm confused by a lot of the discussion in this thread. The chroot utility does not in any way, shape, or form change the system's root directory.
The chroot utility (and the underlying chroot () system call) starts a new process with the root directory for that process (and any descendants of that process) set to the directory specified on the command line in that chroot utility invocation.
The root directory of any processes that were running before chroot was invoked (and any descendants of those processes) continue to run with their original root directory.
From what I see in the manual pages, it appears that fakechroot is only available on Debian Linux systems. It also seems that fakechroot does not actually change the root directory of the process it starts, but the library used by the linker that fakechroot uses to link the process it starts fakes the behavior used to run the process as though it had been chroot ed in some cases while ignoring chroot behavior in other cases.
I believe the chroot utility and system call are available on all recent UNIX, Linux, and BSD systems.
Yes, I believe that is true but also consider the scenario where a Solaris Global Zone boots a non-global zone and then sets (ie, changes) that non-global zones root directory with chroot . The parent (kernel) process of that non-global is now set to a different root directory and that affects all future users logging into that zone.
Therefore my understanding was that if the root user changed the root directory of the global zone kernel (PID 1) that would affect future users that log in??
The process that chroot starts is a new process; it does not replace an existing process (and certainly does not replace PID 1 in the global zone).
You might be able to use chroot to start a non-global zone with an alternative root directory and have that affect all processes run in that zone, but I no longer have access to a system where I could verify whether or not that would work.