mjhjmtu

APUE says

Each process also has a root directory that is used for resolution of absolute pathnames.
This root directory can be changed with the chroot function.

I thought only relative pathnames need resolution. So I was wondering

• what does resolution of absolute pathnames mean?




• how does chroot use a root directory for resolution of absolute pathnames?
  Thanks.

All pathnames need resolution. 
Obviously, processes pass pathnames to the kernel
as arguments to system calls like:

• 
  creat or open,


• 
  link or rename,


• 
  unlink or rmdir,


• 
  chmod or chown,


• 
  chdir or chroot,


• 
  execve,
  

etc. 
Consider a pathname that looks something like

…  a  /  b  /  c

The way the kernel interprets this is:

Starting (somewhere in the filesystem),

Look for a directory called a¹.

    If not found, return an error.

    If found, then search that directory for a subdirectory called b.

        If not found, return an error.

        If found, then search that directory for directory entry called c².

            If not found, return an error³.

            If found, return that inode.

Notice the obfuscation at the beginning of the pathname,
and in the first line of the algorithm. 
It’s simple: if the pathname begins with a slash
(i.e., it’s an “absolute pathname”, e.g., /a/b/c),
the search begins at the process’s root directory,
and if the pathname begins with anything else
(i.e., it’s a relative pathname, e.g., a/b/c),
the search begins at the process’s current working directory.

You may ask “How is this achieved?” 
Well, of course,
the kernel maintains a lot of information about each process, including

• PID, PPID, and various process group identifiers,


• real, effective, and saved UID and GID, and supplementary GID list,
  


• open files,


• signal dispositions,
  

and more. 
I left out many things because they’re irrelevant to this question. 
I left out environment variables because they’re not maintained by the kernel;
they’re maintained by user-space programs. 
All the kernel does is support a mechanism
for passing environment variables from one program to another through execve.

Two things I left out of the above list for dramatic purposes are:

• process’s root directory, and


• current working directory

These are pointers to inodes. 
I expect everybody who has gotten this far
understands how the process’s current working directory is set —
the process calls chdir, passing it a pathname as an argument;
the kernel interprets the pathname (resolves it to an inode)
following the procedure described above,
and, upon success, sets the current directory pointer to point to that inode.

The process’s root directory is set the same way,
except with the chroot system call.

(Note that, in either case, if the pathname argument begins with /,
the pathname resolution starts at the process’s root directory
in effect when the system call is invoked. )

Some examples:

• If your current directory is /home/tim
  (and your process root directory is the filesystem root), then
  
  
  • if you access /etc/services, you will get /etc/services,
  
  
  • if you access .bashrc, you will get /home/tim/.bashrc.
  
  


• If you do chroot /filesystem/tim
  (assuming that there is a directory by that name, and you have access to it,
  and you have the necessary privilege to chroot), then
  
  
  • if you access /etc/services, you will get /filesystem/tim/etc/services,
  
  
  • if you access /, you will get /filesystem/tim, so
  
  
  • if you chroot /, nothing will change;
  
  
  • if you chroot /filesystem/john,
    it will try to chroot to /filesystem/tim/filesystem/john.
  
  

Since the root directory and the current directory
are stored as pointers to inodes, the system doesn’t need to “locate” them.

__________
¹Ã¢Â€Âƒi.e., look for a directory entry that points to an inode whose mode indicates that it is a directory, i.e., (i_mode & IFMT) == IFDIR.

When the kernel resolves e.g. /usr/share/man/man1/cat.1.gz to an inode, it will have to start from the root /, and work its way down to cat.1.gz. In the case of a relative pathname, it needs only look up the file in the current directory.

Maybe you were thinking of how to get the absolute path to the current working directory? To determine the path, you will have to work your way from the current directory, through all the intermediate directories up to the root. (But note that the kernel does not do this when given a relative path to a file, e.g. as a parameter to the open syscall.)