CHROOT(2)

✨ CHROOT(2) ✨ — change root directory 💅

okay so bestie, welcome to CHROOT(2), straight out of the System Calls Manual 🫶 this one is a whole vibe, it's the syscall that literally moves the whole world for your process. sit down, hydrate, let's get into it 🌸

---

🌈 NAME 🌈

chroot — change root directory 🎀

---

📚 LIBRARY 📚

Standard C Library (libc, -lc) ✨

---

🦋 SYNOPSIS 🦋

#include <unistd.h>

int
chroot(const char *dirname);

---

👑 DESCRIPTION 👑

okay so the tea ☕️: the dirname argument is the address of the pathname of a directory, terminated by an ASCII NUL. classic string things, no cap.

The chroot() system call causes dirname to become the root directory, that is, the starting point for path searches of pathnames beginning with ‘/’. it's giving "rewrite the map of the universe" 🗺️✨

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

It should be noted that chroot() has no effect on the process's current directory. 💀 your cwd does NOT move with you, she stays exactly where she was.

This call is restricted to the super-user 👑 — like, sorry bestie, not just anyone gets to do this.

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 🧚

---

💫 RETURN VALUES 💫

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. she'll tell you what went wrong, bestie, you just gotta read her.

---

🚨 ERRORS 🚨

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

• [ENOTDIR] — A component of the path name is not a directory. 😭
• [EPERM] — The effective user ID is not the super-user, or one or more filedescriptors are open directories. 🙈
• [ENAMETOOLONG] — A component of a pathname exceeded 255 characters, or an entire path name exceeded 1023 characters. girl that path is TOO long 💀
• [ENOENT] — The named directory does not exist. she's not there, bestie, she ghosted you 👻
• [EACCES] — Search permission is denied for any component of the path name. 🔒
• [ELOOP] — Too many symbolic links were encountered in translating the pathname. 🌀 symlink maze fr fr
• [EFAULT] — The dirname argument points outside the process's allocated address space. 🫠
• [EIO] — An I/O error occurred while reading from or writing to the file system. ⚡️
• [EINTEGRITY] — Corrupted data was detected while reading from the file system. 💀 corrupted, no cap

---

👀 SEE ALSO 👀

• chdir(2)
• jail(2)

---

📜 HISTORY 📜

The chroot() system call appeared in Version 7 AT&T UNIX 🕰️ iconic behavior honestly. It was marked as “legacy” in Version 2 of the Single UNIX Specification (“SUSv2”), and was removed in subsequent standards. rip bozo 🪦✨

---

🐛 BUGS 🐛

okay this one is the messy part 🙈: 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. so like... she said "no" but also already moved your stuff?? 💀 the state is not what you think it is, check it, always check it.

---

🔐 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 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. 🔥 no cap, do not skip this step, this is the main character energy move that keeps you safe.

---

and that's the whole page bestie, you ate it 💅 this was CHROOT(2) from the System Calls Manual, brought to you by Debian, dated June 26, 2020 🎀 mwah, go chroot responsibly 🦋✨