- Feature Name: proc_tantrum
- Start Date: 2016-04-01
- RFC PR: (leave this empty)
- Rust Issue: (leave this empty)
Allowing arbitrary filesystem paths to be opened allows Rust’s memory safety guarantees to be violated (even without administrative/“root” access, which can be considered the platform-provided equivalent of an unsafe block), as demonstrated in #32670. To close this soundness hole, filesystem access by path should be marked unsafe, the same way creating references by memory address is already unsafe.
To solve a soundness hole. If this soundness hole is not fixed, then all of the machinery and effort in place to make Rust safe is a complete waste of time, and everybody might as well go back to the pervasive unsafety of C and assembler.
The following methods of accessing arbitrary paths exist in Rust:
FromRawFd::from_raw_fd()(which is already unsafe)
- redirecting standard input, output, and error
The first three functions would need to be marked unsafe. Since the fourth is done by the creating process, access to those streams would need to be marked unsafe, which means that the following APIs would additionally need to be marked unsafe:
panic!and it’s relatives (
unwrap(), Box::new, etc)
This would result in a large proliferation of unsafe code, and would break a large number of existing Rust programs.
In the LLVM memory model, reading from padding bytes is undefined behavior, but doing so through the filesystem API is not currently optimized by the compiler, so Rust could possibly get away with only marking the write-level APIs as unsafe and disabling any future LLVM optimizations that would violate this expectation.
We could alternatively give up and get back to writing C++.
Now what will we do with our spare time and Mozilla’s research money?