CHROOT(2) | System Calls Manual | CHROOT(2) |
chroot
— change
root directory
Standard C Library (libc, -lc)
#include
<unistd.h>
int
chroot
(const
char *dirname);
The dirname argument is the address of the
pathname of a directory, terminated by an ASCII NUL. The
chroot
()
system call causes 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
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
chroot
()
fail as follows:
If
‘kern.chroot_allow_open_directories
’
is set to zero,
chroot
()
will always fail with EPERM
if there are any
directories open.
If
‘kern.chroot_allow_open_directories
’
is set to one (the default),
chroot
()
will fail with EPERM
if there are any directories
open and the process is already subject to the
chroot
() system call.
Any other value for
‘kern.chroot_allow_open_directories
’
will bypass the check for open directories
Upon successful completion, the value 0 is returned; otherwise the value -1 is returned and the global variable errno is set to indicate the error.
The chroot
() system call will fail and the
root directory will be unchanged if:
ENOTDIR
]EPERM
]ENAMETOOLONG
]ENOENT
]EACCES
]ELOOP
]EFAULT
]EIO
]The chroot
() system call appeared in
4.2BSD. It was marked as “legacy” in
Version 2 of the Single UNIX Specification
(“SUSv2”), and was removed in subsequent standards.
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.
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 chroot
call, and
restrict write access to a limited subtree of the
chroot
root, for instance, setup the sandbox so that
the sandboxed user will have no write access to any well-known system
directories.
January 3, 2012 | Debian |