Some random thoughts after reading vfork considered dangerous. First and immediate response, yes, vfork is dangerous.

On OpenBSD, vfork has not implemented the memory sharing semantics since forever. The only difference with regular fork is the implicit wait for exec. Mostly, this means some things may be a little slower, but you probably haven’t noticed. The only program I know of that required the memory sharing was wine, which is why wine didn’t work on OpenBSD since forever.

As for posix_spawn, let me first digress and say that if I’m ever in charge of some programming standard, I’m going to reserve the prefix awesome for the standard. Then we’d have cool functions like awesome_spawn and awesome_memalign.

As for signals, OpenBSD uses regular fork for posix_spawn (not that it matters, as per above), although we don’t block signals. I don’t think this should be a problem unless your program is doing something illegal in the signal handler, but I have to ask somebody smart.

Now we get to the fun parts. vfork and threads and setuid. One security feature that OpenBSD has implemented for a long time is that once a process calls setuid, a flag is set that can’t be erased until the next exec. While this flag is set, only root can attach to it, regardless of its current permissions. Even if it completely drops privileges, if it ever had root privs, it’s marked forever to prevent regular user processes from messing with it. So the described exploit doesn’t exist on OpenBSD at least (and wouldn’t even if vfork shared memory).

Threads and setuid are bad news. I can’t think of a responsible reason why you’d ever design a program that uses both features, it’s just asking for trouble. There are some problem spots here in OpenBSD if you were curious. If you start a syscall as one uid, then another thread switches uid, the behavior of the first syscall can be erratic. Just please, for the love of all that’s holy, don’t do this.

One thing that OpenBSD does need to fix is the systrace privilege elevation feature. That interacts poorly with threads as well, for the same reason. systrace bumps privs for the whole process, meaning other threads will also get bonus privs. There is a patch to fix this, but be advised. Here be dragons.