JAIL(2)

✨ NAME ✨

Okay so welcome to the JAIL(2) manual page bestie 💖 — today's main characters are jail, jail_get, jail_set, jail_remove, jail_attach, jail_remove_jd, and jail_attach_jd, and their whole collective vibe is create and manage system jails. Periodt. 👑

📚 LIBRARY 📚

Standard C Library (libc, -lc) — she lives there, iconic behavior fr fr.

🛠️ SYNOPSIS 🛠️

#include <sys/param.h>
#include <sys/jail.h>

int
jail(struct jail *jail);

int
jail_attach(int jid);

int
jail_remove(int jid);

int
jail_attach_jd(int fd);

int
jail_remove_jd(int fd);

#include <sys/uio.h>

int
jail_get(struct iovec *iov, u_int niov, int flags);

int
jail_set(struct iovec *iov, u_int niov, int flags);

🌸 DESCRIPTION 🌸

So the jail() system call sets up a jail and locks the current process in it. Like, it's giving "you're in the contained room now" 🚪✨.

The argument is a pointer to a structure describing the prison:

struct jail {
        uint32_t        version;
        char            *path;
        char            *hostname;
        char            *jailname;
        unsigned int    ip4s;
        unsigned int    ip6s;
        struct in_addr  *ip4;
        struct in6_addr *ip6;
};

• version — defines the version of the API in use. JAIL_API_VERSION is defined for the current version.
• path — the pointer should be set to the directory which is to be the root of the prison.
• hostname — the pointer can be set to the hostname of the prison. This can be changed from the inside of the prison.
• jailname — the pointer is an optional name that can be assigned to the jail, for example for management purposes.
• ip4s and ip6s — give the numbers of IPv4 and IPv6 addresses that will be passed via their respective pointers.
• ip4 and ip6 — the pointers can be set to arrays of IPv4 and IPv6 addresses to be assigned to the prison, or NULL if none. IPv4 addresses must be in network byte order.

⚠️ Heads up bestie: this is equivalent to, and deprecated in favor of, the jail_set() system call (see below), with the parameters path, host.hostname, name, ip4.addr, and ip6.addr, and with the JAIL_ATTACH flag. Not me reading "deprecated" and gasping 😭 — but there it is, keep it in mind.

Next up: the jail_set() system call creates a new jail, or modifies an existing one, and optionally locks the current process in it. Jail parameters are passed as an array of name-value pairs in the array iov, containing niov elements. Parameter names are a null-terminated string, and values may be strings, integers, or other arbitrary data. Some parameters are boolean, and do not have a value (their length is zero) but are set by the name alone with or without a “no” prefix, e.g. persist or nopersist. Any parameters not set will be given default values, generally based on the current environment. 🫶

Jails have a set of core parameters, and modules can add their own jail parameters. The current set of available parameters, and their formats, can be retrieved via the security.jail.param sysctl MIB entry. Notable parameters include those mentioned in the jail() description above, as well as jid and name, which identify the jail being created or modified. See jail(8) for more information on the core jail parameters.

The flags argument consists of one or more of the following flags:

• JAIL_CREATE — create a new jail. If a jid or name parameter exists, they must not refer to an existing jail.
• JAIL_UPDATE — modify an existing jail. One of the jid or name parameters must exist, and must refer to an existing jail. If both JAIL_CREATE and JAIL_UPDATE are set, a jail will be created if it does not yet exist, and modified if it does exist.
• JAIL_ATTACH — in addition to creating or modifying the jail, attach the current process to it, as with the jail_attach() system call.
• JAIL_DYING — this is deprecated in jail_set() and has no effect.
• JAIL_USE_DESC — identify the jail by a descriptor in the desc parameter.
• JAIL_AT_DESC — operate in the context of the jail described by the desc parameter, instead of the current jail. Only one of JAIL_USE_DESC or JAIL_AT_DESC may be specified.
• JAIL_GET_DESC — return a new jail descriptor for the jail in the desc parameter.
• JAIL_OWN_DESC — return an “owning” jail descriptor in the desc parameter.

The jail_get() system call retrieves jail parameters, using the same name-value list as jail_set() in the iov and niov arguments. The jail to read can be specified by either jid or name by including those parameters in the list. If they are included but are not intended to be the search key, they should be cleared (zero and the empty string respectively). 🌀

The special parameter lastjid can be used to retrieve a list of all jails. It will fetch the jail with the jid above and closest to the passed value. The first jail (usually but not always jid 1) can be found by passing a lastjid of zero.

The flags argument consists of one or more of the following flags:

• JAIL_DYING — allow getting a jail that is in the process of being removed.
• JAIL_USE_DESC — same meaning as in jail_set().
• JAIL_AT_DESC — same meaning as in jail_set().
• JAIL_GET_DESC — same meaning as in jail_set().
• JAIL_OWN_DESC — same meaning as in jail_set().

The jail_attach() system call attaches the current process to an existing jail, identified by jid. It changes the process's root and current directories to the jail's path directory.

The jail_remove() system call removes the jail identified by jid. It will kill all processes belonging to the jail, and remove any children of that jail. She's not just closing the door — she's clearing the whole group chat 💀.

The jail_attach_fd() and jail_remove_fd() system calls work the same as jail_attach() and jail_remove(), except that they operate on the jail identified by jail descriptor fd. (Yes, the page says _fd right here — keep it exactly as written, bestie 👀.)

🎀 Jail Descriptors 🎀

In addition to the jail ID, jails can be referred to using a jail descriptor, a type of file descriptor tied to a particular jail. Jail descriptors are created by calling jail_set() or jail_get() with the special parameter desc, and either the JAIL_GET_DESC or JAIL_OWN_DESC flags set. The difference between the two flags is that descriptors created with JAIL_OWN_DESC (called “owning” descriptors) will automatically remove the jail when the descriptor is closed. That's main character energy with cleanup duties 💅.

Jail descriptors can be passed back to jail_set() or with the desc parameter, and either the JAIL_USE_DESC or JAIL_AT_DESC flags set. With JAIL_USE_DESC, the descriptor identifies the jail to operate on, instead of the jid or name parameter. With JAIL_AT_DESC, the descriptor is used in place of the current jail, allowing accessing or creating jails that are children of the descriptor jail. 🧚

The system calls jail_attach_jd() and jail_remove_jd() work the same as jail_attach() and jail_remove(), except that they operate on the jail referred to by the passed descriptor.

🏁 RETURN VALUES 🏁

If successful, jail(), jail_set(), and jail_get() return a non-negative integer, termed the jail identifier (JID). They return -1 on failure, and set errno to indicate the error.

The jail_attach(), jail_remove(), jail_attach_jd(), and jail_remove_jd() functions return the value 0 if successful; otherwise the value -1 is returned and the global variable errno is set to indicate the error. No cap, 0 means slay, -1 means check errno and handle your business 🌈.

💀 ERRORS 💀

ok so this is the part where things can go wrong, and there are a lot of ways for them to go wrong bestie. buckle up 💅

The jail() system call will fail if:

• [EPERM] — this process is not allowed to create a jail. why? either it's not the super-user, or it would blow past the jail's children.max limit. rude but fair.
• [EFAULT] — jail points to an address that's outside the allocated address space of the process. like, that memory isn't yours babe.
• [EINVAL] — the version number of the argument is not correct.
• [EAGAIN] — no free JID could be found. all the jail IDs are taken 😭

---

The jail_set() system call will fail if:

• [EPERM] — this process is not allowed to create a jail, either because it is not the super-user, or because it would exceed the jail's children.max limit.
• [EPERM] — the jail descriptor in the desc parameter was created by a user other than the super-user, and the JAIL_USE_DESC flag was set.
• [EPERM] — a jail parameter was set to a less restrictive value than the current environment. nope, you can't loosen the vibes 🔒
• [EFAULT] — Iov, or one of the addresses contained inside it, points to an address outside the allocated address space of the process.
• [ENOENT] — the jail referred to by a jid or name parameter does not exist, and the JAIL_CREATE flag is not set.
• [ENOENT] — the jail referred to by a jid parameter is not accessible by the process, because the process is in a different jail.
• [ENOENT] — the jail referred to by a desc parameter has been removed.
• [EEXIST] — the jail referred to by a jid or name parameter exists, and the JAIL_UPDATE flag is not set.
• [EINVAL] — a supplied parameter is the wrong size.
• [EINVAL] — a supplied parameter is out of range.
• [EINVAL] — a supplied string parameter is not null-terminated.
• [EINVAL] — a supplied parameter name does not match any known parameters.
• [EINVAL] — one of the JAIL_CREATE or JAIL_UPDATE flags is not set.
• [ENAMETOOLONG] — a supplied string parameter is longer than allowed. too much yapping, respectfully 💀
• [EAGAIN] — there are no jail IDs left.
• [EMFILE] — a jail descriptor could not be created for the desc parameter with either the JAIL_GET_DESC or JAIL_OWN_DESC flag set, because the process has already reached its limit for open file descriptors.
• [ENFILE] — a jail descriptor could not be created for the desc parameter with either the JAIL_GET_DESC or JAIL_OWN_DESC flag set, because the system file table is full.

---

The jail_get() system call will fail if:

• [ENOENT] — the jail referred to by a jid or name parameter does not exist.
• [ENOENT] — the jail referred to by a jid is not accessible by the process, because the process is in a different jail.
• [ENOENT] — the lastjid parameter is greater than the highest current jail ID.
• [ENOENT] — the jail referred to by a desc parameter has been removed (even if the JAIL_CREATE flag has been set).
• [EINVAL] — a supplied parameter is the wrong size.
• [EINVAL] — a supplied parameter is out of range.
• [EINVAL] — a supplied string parameter is not null-terminated.
• [EINVAL] — a supplied parameter name does not match any known parameters.
• [EMFILE] — a jail descriptor could not be created for the desc parameter with either the JAIL_GET_DESC or JAIL_OWN_DESC flag set, because the process has already reached its limit for open file descriptors.
• [ENFILE] — a jail descriptor could not be created for the desc parameter with either the JAIL_GET_DESC or JAIL_OWN_DESC flag set, because the system file table is full.

---

The jail_attach() and jail_remove() system calls will fail if:

• [EPERM] — a user other than the super-user attempted to attach to or remove a jail.
• [EINVAL] — the jail specified by jid does not exist.

---

The jail_attach_jd() and jail_remove_jd() system calls will fail if:

• [EINVAL] — the fd argument is not a valid jail descriptor.
• [EPERM] — the jail descriptor was created by a user other than the super-user.
• [EINVAL] — the jail specified by jid has been removed.

🫶 heads up bestie: further jail(), jail_set(), jail_attach(), and jail_attach_jd() calls do chroot(2) internally, which means they can fail for all the same reasons chroot(2) can. specifically, they return the [EPERM] error when the process trying to join a jail has open directories. go read the chroot(2) manual page for the details, i'm not gatekeeping it from you, it's all right there 💖

---

👀 SEE ALSO 👀

chdir(2), chroot(2), jail(8)

like, go read these next, they're the whole ecosystem okay 🦋

---

🕰️ HISTORY 🕰️

• The jail() system call appeared in FreeBSD 4.0.
• The jail_attach() system call appeared in FreeBSD 5.1.
• The jail_set(), jail_get(), and jail_remove() system calls appeared in FreeBSD 8.0.

the way this has been evolving since the 4.0 era… iconic longevity honestly 👑

---

🌟 AUTHORS 🌟

• The jail feature was written by Poul-Henning Kamp for R&D Associates, who contributed it to FreeBSD.
• James Gritton added the extensible jail parameters and hierarchical jails.

legends, both of them, no cap 💜

---

and that's the whole page bestie, you made it 🎀 this gorgeous little number comes to you from Debian, dated September 15, 2025, filed under JAIL(2) — go forth and jail responsibly ✨💅