File descriptors created by Rust should be automatically close-on-exec

[DemiMarie]

The following code outputs

0
1
2
3

#![feature(old_io)]
#![feature(process)]
#![feature(old_path)]
fn main () {
    use std::old_io::File;
    use std::process::Command;
    let mut file = File::create(&Path::new("message.txt"));
    let _ = file.write_all(b"hello, file!\n");
    let output = Command::new("ls").arg("/dev/fd").output().unwrap();
    let val = output.stdout;
    let _ = ::std::old_io::stdio::stdout().write_all(&val[0..]);
}

This means that Rust is setting the close-on-exec flag for the file descriptor that it created (file descriptor 3 is for the /dev/fd directory). The new io module should that this is also done, and that this is done atomically where possible.

This is mostly a tracking issue to make sure that there is no regression.

[alexcrichton]

The symptoms here are a bit of a red herring, if you take a look at the strace output the file descriptor 3 in the child process is not the file descriptor of the File in the parent process. Instead, it is:

[pid  6521] openat(AT_FDCWD, "/dev/fd", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
[pid  6521] getdents(3, /* 6 entries */, 32768) = 144
[pid  6521] getdents(3, /* 0 entries */, 32768) = 0
[pid  6521] close(3)                    = 0
[pid  6521] fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 24), ...}) = 0
[pid  6521] mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f64121c1000
[pid  6521] write(1, "0  1  2  3\n", 110  1  2  3
) = 11

We have specific code to prevent leaking file descriptors, and it is known to not be bullet proof and is being tracked. In light of this information I'm going to close this in favor of the RFC tracking issue. Thanks for the report though!

[DemiMarie]

Alex Crichton notifications@github.com writes:

The symptoms here are a bit of a red herring, if you take a look at the strace output the file descriptor 3 in the child process is not the file descriptor of the File in the parent
process. Instead, it is:

[pid 6521] openat(AT_FDCWD, "/dev/fd", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
[pid 6521] getdents(3, /* 6 entries /, 32768) = 144
[pid 6521] getdents(3, / 0 entries */, 32768) = 0
[pid 6521] close(3) = 0
[pid 6521] fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 24), ...}) = 0
[pid 6521] mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f64121c1000
[pid 6521] write(1, "0 1 2 3\n", 110 1 2 3
) = 11

We have specific code to prevent leaking file descriptors, and it is known to not be bullet proof and is being tracked. In light of this information I'm going to close this in favor of
the RFC tracking issue. Thanks for the report though!

—
Reply to this email directly or view it on GitHub.*
I knew that this FD was the FD of the /dev/fd directory. I was just
checking to make sure that there is no regression.

Sorry for the confusion. I knew about a nasty FD leak to child
processes in Firefox and wanted to make sure that Rust is safe.

[alexcrichton]

No problem!