[spc476]

Between the `fork()` and an `exec()`, I can:

    * redirect stdin, stdout, and stderr
    * open files that might be needed and close files that aren't
    * change process limits
    * drop privileges 
    * change the root directory
    * change namespaces

And there are a few other things I am probably forgetting.

[the_mitsuhiko]

And ideally all these things become properties to a configuration object which is then used to spawn a process.

[mort96]

I'm not sure I agree it's the ideal way to do it. That's a heck of a lot of work for one function to do, and it necessarily duplicates the functionality of a ton of other functions. And that's ignoring the fact that forking without ever exec'ing can be really useful in many cases.

I haven't yet read the paper, but considering the incredible simplicity from the programmer's PoV that fork provides, and the fact that at least Linux makes it pretty god damn fast, especially compared to Windows' non-forking model, I can't really see myself agreeing with their conclusion.

[eesmith]

When you read the paper, you'll see this covered in section 6 ("REPLACING FORK") subsection "Low-level: Cross-process operations"

> While a spawn-like API is preferred for most instances of starting a program, for full generality it requires a flag, parameter, or new helper function controlling every possible aspect of process state. It is infeasible for a single OS API to give complete control over the initial state of a new process. ...

> 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 ...

> Retrofitting cross-process APIs into Unix seems at first glance challenging, but may also be productive for future research.

[cryptonector]

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

[Dylan16807]

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

[cryptonector]

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".

[a1369209993]

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...)

[GoblinSlayer]

Less general functions can call more general functions, like fork calls clone on Linux.

[JdeBP]

You could call it posix_spawn_file_actions_t and posix_spawnattr_t . (-:

[cryptonector]

You can do all of that with posix_spawn() as well, though some of those may require a helper program.