tmppath promise removed from pledge(2) in -current

A long standing and somewhat odd conflict between two OpenBSD security mechanisms, pledge(2) and unveil(2) has been resolved by eliminating the tmppath promise from what pledge(2) offers.

The commit by Theo de Raadt (deraadt@) comes with an explanation in the commit message, which reads

List:       openbsd-cvs
Subject:    CVS: cvs.openbsd.org: src
From:       Theo de Raadt <deraadt () cvs ! openbsd ! org>
Date:       2026-02-26 7:42:26
CVSROOT:	/cvs
Module name:	src
Changes by:	deraadt@cvs.openbsd.org	2026/02/26 00:42:26

Modified files:
	sys/sys        : pledge.h 
	sys/kern       : kern_pledge.c 
	lib/libc/sys   : pledge.2 

Log message:
pledge "tmppath" goes away because it sucks.  The history is kind of
sad:  unveil(2) was invented by Bob Beck and myself because a couple
of us struggled and couldn't expand the "tmppath" mechanism to general use.

unveil(2) ended up being kind of "upside down" different, and so we never
deleted "tmppath" because the refactorings seemed complicated.
However over the last two weeks, we're removed all the "tmppath" in base
pretty easily, and the 18 ports using it have also been fixed.
The majority of situations now use unveil "/tmp" "rwc", unveil "/" "r" or
similar, and then pledge "rpath wpath cpath", and this is generally needed
to satisfy the mkstemp(3) family of functions in libc.
Use of "tmppath" will now cause pledge(2) to return EINVAL.  There is
no backwards compatible way of mimic the behaviour correctly using
kernel-internal unveil hackery.
Prompted by a report from David Leadbeater; and extensive conversations
with beck and semarie.

The code is in snapshots now, and the developers are as always interested to hear of any breakage not yet detected.

So please do go ahead, fetch a snapshot and test!