int chroot(const char *path);
glibc 向けの機能検査マクロの要件 (feature_test_macros(7) 参照):
chroot():
_XOPEN_SOURCE && ! (_POSIX_C_SOURCE >= 200112L)
|| /* glibc 2.20 以降: */ _DEFAULT_SOURCE
|| /* glibc 2.19 以降: */ _BSD_SOURCE
特権プロセス (Linux では、ユーザー名前空間に CAP_SYS_CHROOT ケーパビリティを持つプロセス) のみが chroot() を呼び出すことができる。
このコールはパス名解決の過程で構成要素を変更するのみで、 その他には何も行わない。 特に、これは何らかのセキュリティ上の目的を意図しておらず、 プロセスの完全なサンドボックスになる訳でも、 ファイルシステムのシステムコールを制限する訳でもない。 かつては、 chroot() は、信用できないユーザーから指定されたパスを、 open(2) のようなシステムコールに渡す際に、デーモンがそのパスを前もって 制限するのに使われていた。 しかし、フォルダが chroot ディレクトリの外に出されてしまうと、 攻撃者も chroot ディレクトリの外に出て悪用できてしまう。 これを行う最も簡単な方法は、移動される予定のディレクトリに chdir(2) しておいて、外に出されるのを待ち、 ../../../etc/passwd のようにパスをオープンすることである。
ちょっとトリッキーな派生型を使うと、 chdir(2) が許可されていない環境でも動作する。 デーモンに "chroot ディレクトリ" を許可する指定がされている場合、 リモートユーザーが chroot ディレクトリの外にアクセスするのを防止するには、 フォルダを chroot ディレクトリの外に絶対に出さないようにしなければならない。
このコールは現在の作業ディレクトリ (working directory) を変更しない。 そのため、このコールの後に '.' が '/' を 根とするツリーの外になる場合がある。 特に、スーパーユーザーは以下のようにすることで "chroot jail" から逃げ出せてしまう。
mkdir foo; chroot foo; cd ..
このコールはオープンファイルディスクリプターをクローズしないので、 このようなファイルディスクリプターは chroot ツリーの外にある ファイルにアクセスできる。
マジックシンボリックリンク /proc/[pid]/root を使って、プロセスのルートディレクトリを見つけることができる。 詳細は proc(5) を参照すること。
FreeBSD にはより強力な jail() システムコールがある。