Index | Thread | Search

From:
Benjamin Lee McQueen <mcq@disroot.org>
Subject:
Re: trivial pledge for arch(1)
To:
Theo de Raadt <deraadt@openbsd.org>
Cc:
Tech <tech@openbsd.org>
Date:
Wed, 11 Feb 2026 19:18:27 +0100

Download raw body.

Thread
On 2026-02-11 18:37, Theo de Raadt wrote:

> But why should it do pledge?

from the manpage:
"The pledge() system call forces the current process into a
restricted-service operating mode. A few subsets are
available, roughly described as computation, memory
management, read-write operations on file descriptors,
opening of files, networking (and notably separate, DNS
resolution). In general, these modes were selected by
studying the operation of many programs using libc
and other such interfaces, and setting promises or
execpromises."

basically just restricts what it can do, and arch only
needs stdio. so only letting it perform stdio, shrinks
what the process is allowed to do if it ever misbehaves.

> Should it do unveil also?
no, as the man page states,

"The first call to unveil() that specifies a path removes
visibility of the entire filesystem from all other
filesystem-related system calls (such as open(2), chmod(2)
  and rename(2)), except for the specified path and
permissions."

unveil is basically only useful when a program interacts
with the filesystem.

> How about attempting to chroot in case it is run by root?
from manpage:
"The chroot command changes its root directory to the supplied
directory newroot and executes command, if supplied, or an
interactive copy of the user's shell."

even if root runs it, chroot only helps when the program is
priviledged service that actually needs its filesystem view
restricted. arch(1) doesn't hold any priviledges or touch
the filesystem, so its not needed.