Likely unnecessary write access to a file

[3Hren]

Hi!

While playing with wasmer as an embeddable wasm execution engine I discovered that wasmer-wasi requests more wide file-access than required in the code during opening a file.

For example:

let file = File::open("/proc/uptime")?;

fails without root permissions, while it shouldn't.

Stracing resulted in:

[pid 18721] openat(AT_FDCWD, "./uptime", O_RDWR|O_CLOEXEC = -1 EACCES (Permission denied)

In pure Rust, this opens /proc/uptime in O_RDONLY mode. In the case of wasmer-wasi it also requests write-access (O_RDWR). Here is the suspected code:

wasmer/lib/wasi/src/syscalls/mod.rs

Line 1464 in 9aac20e

let open_options = open_options.read(true).write(true);

Is this a bug or I'm doing something wrong?

PS. I preopened /proc and even changed the working directory to it. However, it is quite strange for me why the full open path is stripped to just ./uptime.

OS: linux 5.0.3, x86_64 x86_64 GNU/Linux
Version = 0.4.1

[MarkMcCaskey]

Thanks for reporting this!

The current file abstraction was never intended to last long-term and it's showing a lot of issues -- things like this and working portably across Unix and Windows. The location of the code where the file is being opened here doesn't know whether the file will need to be written to or not. The reason it's even being opened here is that I was trying to be conservative in regards to the file system changing during program execution but it seems that's not something we can reasonably handle right now.

It seems a completely abstracted WASI file system with security checks on every interaction with the host file system is the way to go to fix things like this

edit: removed the edit that was for a different comment

[MarkMcCaskey]

So it turns out I overestimated the scope of the problem!

We can fix it without updating our abstractions!

Thanks for reporting this!

[3Hren]

Awesome! Thanks!