That has security considerations when spawning a process to run an executable that gets privilege on exec (think set-uid on Unix).

Easy to deal with by not applying privileges until the parent is done tinkering and hits start.

I don't see how. The privilege elevation mechanism cannot apply to an already-running process, since then there will be a way to subvert the process.

Now, the better answer to that is to have nothing like a set-uid mechanism, which would be nice, for sure. But just how much violence are we to do to the Unix model, and when are we expected to finish this? It's not like Linux can be abandoned -- for better or worse, Linux "won".

The paper suggests:

> a new process starts as an empty address space, and an advanced user may manipulate it in a piecemeal fashion, populating its address-space and kernel context prior to execution, without needing to clone the parent nor run code in the context of the child. ExOS [43] implemented fork in user-mode atop such a primitive. Retrofitting cross-process APIs into Unix seems at first glance challenging, but may also be productive for future research.

Specifically, you'd want to do something like:

  pid_t child = pfork();
  for(int fd=0;fd<3;fd++) p_open2(child,fd,pts,O_RDWR);
  char** envp = munge_env(/*parent's*/ environ);
  int err = p_execve(child,file,argv,envp);

(Y'know, this looks kind of familiar...)

I'm really not sure what you're implying, can you please state it explicitly? I'd expect this code to look similar to both the CreateProcess and fork models, at the very least.

a1369209993's example snippet appears to be what is implied from section 6 ("REPLACING FORK"), subsection "Low-level: Cross-process operations":

> clean-slate designs [e.g.,40, 43] have demonstrated an alternative model where system calls that modify per-process state are not constrained to merely the current process, but rather can manipulate any process to which the caller has access. This yields the flexibility and orthogonality of the fork/exec model, without most of its drawbacks: a new process starts as an empty address space, and an advanced user may manipulate it in a piecemeal fashion, populating its address-space and kernel context prior to execution, without needing to clone the parent nor run code in the context of the child.

> a1369209993's example snippet appears to be what is implied from section 6 ("REPLACING FORK"), subsection "Low-level: Cross-process operations"

Oh definitely. But why are they saying it "looks kind of familiar..."? That subsection is already the subject of the conversation. Surely they're not saying it looks similar to itself, right?

Ahh. I thought it was familiar because it was the way one would write that sort of code now, in a fork/exec environment, only replacing the call to change local information into ones to change the child's information.

vfork() is the right tool. I dunno what semantics you have in mind for p_execve().

(See man (2)execve.)

  int p_execve(pid_t target,char* filename,
               char** argv,char** envp);

Executes a new program, specified by filename, in the context of the specified process. On success, the text, data, bss, and stack of the process specified by target are overwritten by that of the program loaded.

A target of zero specifies the current process, so p_execve(0,file,argv,envp) is equivalent to execve(file,argv,envp).

BUGS

We should probably require some kind of permission check before allowing the calling process to do this.