← Back to context

Comment by eesmith

7 years ago

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.

11 comments

eesmith

Reply
cryptonector  7 years ago

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

  • Dylan16807  7 years ago

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

    • cryptonector  7 years ago

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

      1 reply →

    • a1369209993  7 years ago

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

      6 replies →