Skip to content
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

Closed
mstewartgallus opened this issue Jun 4, 2013 · 6 comments
Labels
A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows E-hard Call for participation: Hard difficulty. Experience needed to fix: A lot.

Comments

@mstewartgallus
Copy link
Contributor

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

@emberian
Copy link
Member

emberian commented Aug 5, 2013

/cc @brson

@toddaaro
Copy link
Contributor

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

@alexcrichton
Copy link
Member

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 rt::io::native::process module once the libuv bindings have landed.

@thestinger
Copy link
Contributor

#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,

@vn971
Copy link
Contributor

vn971 commented Apr 22, 2018

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

@Allen-Webb
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows E-hard Call for participation: Hard difficulty. Experience needed to fix: A lot.
Projects
None yet
Development

No branches or pull requests

7 participants