Rust programs started with closed stdio streams may corrupt files|sockets|etc

[theastrallyforged]

For example, if a program is started with ./foo >&- (stdout closed, stdin and stderr open), println!()s fail silently (despite strace showing that write(2) clearly returns -1 and EBADF). If a file is opened and then a println!() is attempted, it silently writes into the file (which is probably not what was intended).

Example 1:

fn main() {
    println!("Hello, world!");
}

Invocation: target/debug/hello-world >&-
Expected result: panic, with an error message relating to being unable to write to stdout, exit code 101
Observed result: nothing (no output on stderr, exit code 0)

Example 2:

fn main() {
    let file = std::fs::File::create("foo").unwrap();
    println!("Hello, world!");
    drop(file);
}

Invocation: target/debug/hello-file >&-
Expected result: panic (as before), empty file ./foo
Observed result: no panic, ./foo contains Hello, world!

Rust version: 1.30.0
Platform: x86_64-unknown-linux-gnu

It looks like any Rust program which is started with one or more closed stdio streams, opens a file (or socket, or…), and subsequently tries to read|write said stdio stream will inadvertently read|write the file instead (messing up the seek position, not to mention causing data corruption). This seems like terribly bad behavior. ;-;

[redengin]

it appears that this is the conventional expectation of OS kernels.

https://stackoverflow.com/questions/22367920/is-it-possible-that-linux-file-descriptor-0-1-2-not-for-stdin-stdout-and-stderr

While I don't believe this should be allowed by the OS kernels, making Rust ensure that it doesn't use "reserved" file descriptors would break programs that rely on this corner-case.

As this really is an OS level behavior, I think this needs input from OS Security architecture (SELinux, AppArmor, etc.)

[theastrallyforged]

Kernel compliance or no, it doesn't seem okay to me that a program can open a fs::File, try to write to io::Stdout, and, through no fault of its own, inadvertently corrupt the file.

[bluss]

This seems to be a known problem of the C/POSIX platforms at least as described in Secure Programming Cookbook for C and C++ chapter 1.5

[sfackler]

I don't think there's anything we can do here. On Unix platforms, stdout is by definition file descriptor 2.

[Amanieu]

We could check at startup whether FD 0/1/2 are open using fcntl(F_GETFD) (which returns EBADF if the FD is closed).

I am not sure what we can do with this information, but I am not very familiar with the I/O parts of the standard library.

[theastrallyforged]

If during startup we discover that any of those streams are closed, we can set a flag in the relevant std::io structures to indicate that all accesses should return Err without attempting a syscall.

[theastrallyforged]

As a data point, cat (GNU cat on my Ubuntu system) doesn't have this issue (it doesn't output anything, but at least it doesn't try to write to its input files). strace shows that everything that opens a file gets an FD of at least 3:

(Contrast the Rust programs, where the first thing to open a file gets FD 1.)

At the end, when it actually gets to opening foo, it gets an FD of 3 as well. No idea where FD 1 is coming from given that 1. it was closed by the shell (>-) and 2. the output doesn't appear on my terminal but 3. strace shows that the writes (to FD 1) succeed.

As I've just realized and as Amanieu has pointed out, >- is not how you close stdout.

cat is still unaffected; cat foo >&- on my system produces cat: standard output: Bad file descriptor. It looks like it just detects that by doing fstat(1, _). Not sure how useful that is to us.

[Amanieu]

You need to use >&-, not >-.