3 ms·

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

Dylan16807 8y ago
Easy to deal with by not applying privileges until the parent is done tinkering and hits start.
- a1369209993 8y 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...)
  - Dylan16807 8y ago
    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.
    - eesmith 8y ago
      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.
      - Dylan16807 8y ago
        > 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?
        eesmith 8y ago
        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.
  - cryptonector 8y ago
    vfork() is the right tool. I dunno what semantics you have in mind for p_execve().
    - a1369209993 8y ago
      (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.
- cryptonector 8y 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".
  - eesmith 8y ago
    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.

Dylan16807 8y ago

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

a1369209993 8y 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...)
- Dylan16807 8y ago
  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.
  - eesmith 8y ago
    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.
    - Dylan16807 8y ago
      > 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?
      - eesmith 8y ago
        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.
- cryptonector 8y ago
  vfork() is the right tool. I dunno what semantics you have in mind for p_execve().
  - a1369209993 8y ago
    (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.
cryptonector 8y 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".
- eesmith 8y ago
  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.