- Feature Name: proc_tantrum
- Start Date: 2016-04-01
- RFC PR: (leave this empty)
- Rust Issue: (leave this empty)
Summary
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.
Motivation
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.
Detailed design
The following methods of accessing arbitrary paths exist in Rust:
File::create()File::open()OpenOptions::open()-
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:
-
println! and print!
-
panic! and it’s relatives (unreachable!, unwrap(), Box::new, etc)
-
io::stdin(), io::stdout(), io::stderr()
Drawbacks
This would result in a large proliferation of unsafe code, and would break a large number of existing Rust programs.
Alternatives
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++.
Unresolved questions
Now what will we do with our spare time and Mozilla’s research money?
