Out of the changes in my original proof-of-concept patch, I've
submitted the most obviously self-contained ones at this point.
There are a few small changes scattered around the code, but it
would make sense to wait and submit them in a bigger group as
they're all pretty much the same thing.

The rest of the substantial changes depend on FreeBSD's
mkostempsat() function. For testing, I've written a workaround
got_opentemp_namedat() involving two chdirs - It's ugly and not
something that can be committed. It's also possible to keep
using got_opentemp_named() and such, but that also adds some
extra path-modification code around them.

There was discussion of adding mkostempsat to OpenBSD:
(apologies if I'm not using email right)

On Wed, Nov 25, 2020 at 12:39 PM Todd C. Miller <Todd.Miller@sudo.ws> wrote:
>
> On Wed, 25 Nov 2020 14:05:28 -0500, Ed Maste wrote:
>
> > Some of the functionality
> > that exists in FreeBSD comes as a natural consequence of that - e.g.
> > mkostempsat is needed when there's no concept of "/" in the sandbox.
> > Similarly AT_FDCWD isn't usable in the sandbox.
>
> FWIW, adding mkostempsat(3) to OpenBSD is trivial to do.  I have
> no objection to adding it...

I'm not familiar with the process of making contributions to
OpenBSD. What would it take to add mkostempsat?

Also, if mkostempsat does get added, I imagine that it'll go into
the next OpenBSD release. So, if I add changes to got that depend
on mkostempsat, got won't be compatible with this and earlier
versions of OpenBSD, I imagine. Is this a problem?