chroot(2) change root directory

LIBRARY

Lb libc

SYNOPSIS

In unistd.h Ft int Fn chroot const char *dirname

DESCRIPTION

The Fa dirname argument is the address of the pathname of a directory, terminated by an ASCII NUL. The Fn chroot system call causes Fa dirname to become the root directory, that is, the starting point for path searches of pathnames beginning with `/'

In order for a directory to become the root directory a process must have execute (search) access for that directory.

It should be noted that Fn chroot has no effect on the process's current directory.

This call is restricted to the super-user.

Depending on the setting of the `kern.chroot_allow_open_directories' sysctl variable, open filedescriptors which reference directories will make the Fn chroot fail as follows:

If `kern.chroot_allow_open_directories' is set to zero, Fn chroot will always fail with Er EPERM if there are any directories open.

If `kern.chroot_allow_open_directories' is set to one (the default), Fn chroot will fail with Er EPERM if there are any directories open and the process is already subject to the Fn chroot system call.

Any other value for `kern.chroot_allow_open_directories' will bypass the check for open directories

RETURN VALUES

Rv -std

ERRORS

The Fn chroot system call will fail and the root directory will be unchanged if:

Bq Er ENOTDIR
A component of the path name is not a directory.
Bq Er EPERM
The effective user ID is not the super-user, or one or more filedescriptors are open directories.
Bq Er ENAMETOOLONG
A component of a pathname exceeded 255 characters, or an entire path name exceeded 1023 characters.
Bq Er ENOENT
The named directory does not exist.
Bq Er EACCES
Search permission is denied for any component of the path name.
Bq Er ELOOP
Too many symbolic links were encountered in translating the pathname.
Bq Er EFAULT
The Fa dirname argument points outside the process's allocated address space.
Bq Er EIO
An I/O error occurred while reading from or writing to the file system.

HISTORY

The Fn chroot system call appeared in BSD 4.2 It was marked as ``legacy'' in St -susv2 , and was removed in subsequent standards.

BUGS

If the process is able to change its working directory to the target directory, but another access control check fails (such as a check for open directories, or a MAC check), it is possible that this system call may return an error, with the working directory of the process left changed.

SECURITY CONSIDERATIONS

The system have many hardcoded paths to files where it may load after the process starts. It is generally recommended to drop privileges immediately after a successful call, and restrict write access to a limited subtree of the root, for instance, setup the sandbox so that the sandboxed user will have no write access to any well-known system directories.