Contact: peter.heiss@uni-muenster.de
Idea taken from fuzion (programming language) https://flang.dev/talks/gpn20 The talk is in german, but the general idea i want to refer to, can be seen in bottom of the linked webpage. Click on any "effects" button there.
Effects means hear, that there is a resource which will be used (see fuzion). It should not be confused by side effects in other contexts.
Keep track on used local resources like accessing stdout, stderr, networking or usb devices. This helps to get an overview of functionalities, which are used by crates.
This could be handy to solve problems such as log4shell, because this function was hide behind an information overload. No one had an idea, that this network function even exist in log4j. And rust is not able to handle such kind of problems.
In practice, this implements a system which is very equal to android permission system. Also it helps for embedded systems, where you do not support some resources.
If such a function would be in rust core, crate developer could create code which recognize such restrictions and omit functions which dos not work in your environment. (like they did already with crate features)
Of course this could be handled through crates features, but this has to support by crate creators. Effects restriction would allow crate user to analyze behaviour of crates without reading the crate code. Also crate creator could write code which can changed behaviour if there is a resource not available (because of permission).
The granularity of such a feature will be a big point to discuss.
You can see, that a crate has a function or crate dependency, so it can connect over network. Now you know there is something and you can do your research, if it is a problem for you.
As a second step, we can create permissions or restrictions on specific effects, the program can use or not permitted to use. In such a case, the compiler would not compile or the tool should print an error message to prevent the compiler to go.
pub fn main() {
println!("hello world");
}# Cargo.toml
[package]
name = "hello_world"
version = "0.1.0"
[dependencies]# bash
$ cargo effects
io.out
$ cargo run
hello worldSee added option "effects" in Cargo.toml
# Cargo.toml
[package]
name = "hello_world"
version = "0.1.0"
[dependencies]
[effects]
needs = ["io.out"]# bash
$ cargo effects
io.out
$ cargo run
hello worldSee effect option, which has empty list of permission. This would be handy to define restrictions.
# Cargo.toml
[package]
name = "hello_world"
version = "0.1.0"
[dependencies]
[effects]
needs = []# bash
$ cargo effects
io.out
$ cargo run
Effects error: Not permitted access to `io.out`.pub fn main() {
eprintln!("hello world");
}# Cargo.toml
[package]
name = "hello_world"
version = "0.1.0"
[dependencies]
[effects]
needs = ["io.out"]# bash
$ cargo effects
io.err
$ cargo run
Effects error: Not permitted access to `io.err`.- io
- out
- err
- in
- file
- network
- usb devices
- time
- nano
- random generator
- panic
- envir
- vars
- exit (call to exit program)
- Do rust needs this kind of feature???
- Can be this achieved by analyze the called methods in libc?
- Do i need to keep track which function uses which resource or does it already?
- Is it possible to implement this in a separate program to analyze the code / called methods in libc? (fuzion implements it with a state while compiling to keep track used resources.)
- Do i need to take a look into intermediate rust files?
- Or does it needs adjustments in the rust core?
If we can keep track of called methods into libc through crates dependencies etc. there would be a need to filter it for resource methods. After this we can print out simpler names like io.out.