handles(7)
MILESTONE-QUALIFIED
Rendered from the page's mdoc source at milestone/general-usability-qemu-20260927 (platform ff025b1)
with GNU groff version 1.23.0, using the same command the image build uses; an ABSD session running
man 7 handles prints this text. It is dated 2026-09-27; the build commands and
repository files it mentions are in private sources, and later work is not in it.
All pages.
HANDLES(7) Miscellaneous Information Manual HANDLES(7) NAME handles -- handles, rights, and the authority of a session DESCRIPTION On ABSD a process can do exactly what the handles it holds allow, plus starting programs if it holds the spawn right. There are no users, no permission bits, and no ambient access to devices or files. Handles A handle is an opaque value, private to one process, that names one kernel object: a pipe, a process, a cell (a small versioned value), the console, the block device, or the network card. The kernel looks a handle up only in the calling process's own table; a stale, guessed, or wrong-kind value is refused (error -9). Rights Each handle carries rights: read, write, wait, and kill. An operation that needs a right the handle lacks is refused (error -1). Rights only narrow: a process can make a second handle to the same object with fewer rights, never more, and a handle copied into a child at start never has more rights than the parent's. Handles move only when a process is started, and always as copies. There is no passing of handles over pipes, and process handles are never given away: only the parent holds one for its child. The spawn right is not a handle right but an attribute of the process. A child inherits it unless its parent withholds it, and nothing restores it. Without it a process cannot start anything. Parentage, adoption by init, a PID, or a restart never grants a right. Files are not handles A file is not a kernel object. A process reaches files through a file server channel, and the server keeps that channel's mount list; see filesystem(7). A process may have the server bind a spare channel for a child with its own mounts or fewer, never more. The authority of a session The SSH server gives a session's first process (the shell, or an `ssh host command' command) exactly: o three pipes: standard input, output, and error; o one file server channel bound to /home/operator and /tmp/session-N read-write and /bin, /etc, /share read-only, and, for a shell, up to two spare channels for its commands; o the working directory / and an empty environment; o the spawn right, only if it is the shell; o for an interactive shell only, a session control channel: two pipes to the SSH server, one on which the server tells the shell of ^C and answers it, one on which the shell asks for ps(1), shutdown(8), or reboot(8). The shell never gives it to a command. It gets no console, no network card, no block device handle of any kind, no machine handle, and no way to reach /ssh. Stopping or restarting the machine takes a machine handle, which only init holds; a session asks the SSH server, which ends its sessions and exits, and init decides. This is the ceiling. The shell's authority is derived from it, and a command's from the shell's, and each step may only narrow: a command gets the shell's mounts, the same read-only (ro), or none (nofs); see absd-sh(1). A command whose output is redirected to a file holds a pipe, not the file, and gains no authority over that file or any other. Commands run directly by `ssh host command' cannot start anything. When the session ends its channels are released, and anything it left running loses its filesystem authority. SEE ALSO absd-sh(1), filesystem(7), process(7) In the kernel repository: docs/TERMINOLOGY.md (Authority) and docs/PROCESS-STARTUP.md. CAVEATS One operator: every session has the same ceiling and shares /home/operator; the only files one session has that another cannot reach are in its /tmp/session-N. A process holding a handle with no rights to a pipe can still learn how full that pipe is. ABSD September 27, 2026 HANDLES(7)