-
Notifications
You must be signed in to change notification settings - Fork 13k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rust needs a high level interface to the system's process fork facilities #6930
Comments
/cc @brson |
/cc @alexcrichton Your current work attacks one aspect of this. As to the actual issue I am a little bit skeptical, but I think the security implications could merit some investigation when we make it to "feature" work on the new runtime. |
This sounds a lot more like an external library thing than a standard library thing, but the standard library should definitely provide access to the OS's forking facilities. I plan on adding a |
#9568 blocks this, but we won't ever be able to have a high-level safe fork because third party libraries are not fork safe, |
// For those who might stumble across this issue accidentally. Currently there is https://doc.rust-lang.org/std/os/unix/process/trait.CommandExt.html#tymethod.exec which might be what you were looking for. |
One big edge case that needs to be covered here is the parent process might have multiple threads some of which can be owners of various things that will not be cleaned up since the threads won't exist in the forked copy (at least for POSIX). Having well defined behavior for forking processes would be nice, but getting it right across all the supported systems may be challenging. Chromium is a good example of something that uses fork to spawn child processes that self-sandbox to drop privileges and reduce attack surface. The way to do this kind of thing today is to use the fork syscall directly early when the process is setting things up before threads are created and use inherited file descriptors /etc as ways to communicate between processes. |
For many purposes it is needed to have complete isolation of memory, and permissions between tasks. The simplest and most portable way of doing so is by spawning new processes. Rust needs new functionality to spawn copies of the original process, and send them to do tasks. This "spawn_process" function would have a type similar to fn spawn_process (~fn : Copy Send Const ()) -> PID, and would have semantics such that all unsafe globally mutable state is reset to the processes initial state (for security purposes, consider if a process that holds sensitive data spawns a copy of itself with lower permissions that still has that data in memory, and then gets attacked.)
The text was updated successfully, but these errors were encountered: