> * Decide whether "setxid problem"[5] is important enough to worry about.
> [5] https://ewontfix.com/7

This is a scary issue.  But I think a reasonable approach could be to never use vfork when running as whatever we choose to define a "privileged user" to be.

getuid() or geteuid() return 0?  don't use vfork.

the concept of "privileged user" can obviously mean a lot more than that and likely goes beyond what we should attempt to ascertain ourselves.

How about also providing a disable-only global setting so that someone writing code they consider to have elevated privileges can prevent its use entirely.  subprocess.disable_use_of_vfork() and subprocess.is_vfork_enabled() calls perhaps (just setting/reading a static int vfork_disallowed = 0 flag within _posixsubprocess.c).

If we did that, on systems where posix_spawn() _might_ be implemented using vfork() we'd want to avoid using it based on is_vfork_enabled().

True setuid vs vfork attack security would suggest code needs to opt-in to vfork() or posix_spawn() rather than opt-out.  Which would destroy the benefit for most users (who won't bother) for the sake of an issue that just is not what most code ever does (setuid/setgid/etc. calls are very uncommon for most software).

I think documenting "HEY, if you are running as with elevated privileges, here's a reason why you might want to disable vfork, and how to do it." should be enough.  Hopefully not famous last words.