Re: chroot documentation

[James Youngman]

On Tue, Apr 21, 2009 at 6:35 PM, Stefano Carucci <address@hidden> wrote:
>
> Hello all!
>
> Can anyone suggest to me a detailed guide about the chroot implementation ?

The implementation in coreutils or the one in your kernel?    The
implementation of chroot(1) in coreurils looks pretty much like this:

chroot("the-specified-directory")
chdir("/")
execvp(your_program_name, argument_list);

If that looks very short, well, it is.   The coreutils implementation
of chroot is only 115 lines, including header comment, option parsing,
and error handling.

> What I am interested in is how it creates the new root,

It doesn't.   The directory to which you chroot must already exist.

> what the computational effort is

Minimal.

# /usr/bin/time -v chroot /var/vserver/chroot/debian/etch/x86/a /bin/true
        Command being timed: "chroot
/var/vserver/chroot/debian/etch/x86/a /bin/true"
        User time (seconds): 0.00
        System time (seconds): 0.00
        Percent of CPU this job got: 266%
        Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.00
        Average shared text size (kbytes): 0
        Average unshared data size (kbytes): 0
        Average stack size (kbytes): 0
        Average total size (kbytes): 0
        Maximum resident set size (kbytes): 0
        Average resident set size (kbytes): 0
        Major (requiring I/O) page faults: 0
        Minor (reclaiming a frame) page faults: 293
        Voluntary context switches: 3
        Involuntary context switches: 0
        Swaps: 0
        File system inputs: 0
        File system outputs: 0
        Socket messages sent: 0
        Socket messages received: 0
        Signals delivered: 0
        Page size (bytes): 4096
        Exit status: 0



> and what it does at a low-level; not just a synopsis.

If you want to know what it does at a low level, you are better off
enquiring into the properties of the implementation, not the
command-line tool that thinly wraps the system call.   You might want
to download the sources for Linux or for some *BSD kernel or some such
thing, in order to understand how the system call works.  But this
mailing list isn't really the right place to enquire about the
internals of those kernels, since we don't write them.

James.