Potential double close in PtyMaster

[asomers]

PtyMaster implements Drop to close its RawFd. However, it ignores errors, because the caller may have manually closed the RawFd. This is bad, because it can lead to double closes, like this:

{
    let m = posix_openpt(O_RDWR);		# Creates a pty with file descriptor 3
    close(m.master);				# Close file descriptor 3
    let f = std::fs::File::create("foo");	# Creates a file with file descriptor 3
}						# PtyMaster::Drop closes file descriptor 3
f.write("whatever");				# fails with EBADF

There are three possible solutions:

1. Always check for errors in PtyMaster::Drop
2. Don't implement PtyMaster::Drop; make the caller responsible for closing it. If we go this route, we should also add a PtyMaster::close method.
3. Change PtyMaster to wrap an Option<RawFd> and have the close method set it to None. That way, the drop method will know whether to call close.

I prefer option 1, but I could go with any of these solutions.

[asomers]

Also, the exact same problem is present in SignalFd. For consistency, we should fix both classes the same way.

[Susurrus]

Note that your example doesn't actually work since f goes out of scope when the block drops.

[asomers]

Touche. How about this:

let f = {
    let m = posix_openpt(O_RDWR);		# Creates a pty with file descriptor 3
    close(m.master);				# Close file descriptor 3
    std::fs::File::create("foo");	        # Creates a file with file descriptor 3
}						# PtyMaster::Drop closes file descriptor 3
f.write("whatever");                            # fails with EBADF	

[Susurrus]

👍

For option 1, what do we do when we detect an error? I think all you can do in Drop is panic, is that what we want to do?

[asomers]

The same issue was discussed in libstd at rust-lang/rust#19028 . Panicing during drop is frowned upon because drop runs during stack unwinding. But in this case I think it's the best option. Let's panic in EBADF and ignore other errors like EIO. And once we're satisfied with our solution, we should file another issue for FileDesc at libstd.

[Susurrus]

@asomers Just realized that you assigned this to me. So I guess I'll dig into this :-)

So here's a working version:

extern crate nix;

use std::io::prelude::*;
use std::os::unix::io::IntoRawFd;

fn main() {
    let mut f = {
        let m = nix::pty::posix_openpt(nix::fcntl::O_RDWR).unwrap();
        nix::unistd::close(m.into_raw_fd()).unwrap();
        std::fs::File::create("foo").unwrap()
    };
    f.write("whatever".as_bytes()).unwrap();
}

And here's one that fails at the f.write() call with error code 9 "Bad file descriptor":

extern crate nix;

use std::io::prelude::*;
use std::os::unix::io::AsRawFd;

fn main() {
    let mut f = {
        let m = nix::pty::posix_openpt(nix::fcntl::O_RDWR).unwrap();
        nix::unistd::close(m.as_raw_fd()).unwrap();
        std::fs::File::create("foo").unwrap()
    };
    f.write("whatever".as_bytes()).unwrap();
}

So I actually think this behavior is correct. Or should close have actually failed here?

[asomers]

@Susurrus I just now started working on this myself! Do you want me to self-assign it and take care of it? I think your first example is correct. But I think the second example should've failed when m got dropped.

[Susurrus]

@asomers I just want you to use the assign field correctly! :-P

You seem to understand this issue, so you're welcome to take this.

Also, when writing out this code example I think that unistd::close() should actually take a T: IntoRawFd which improves its ergonomics a bit. Any thoughts on that? Also many other functions should take AsRawFd where appropriate. That'll make working with posix_openpt or any wrapper type we eventually implement much more ergonomic.

[asomers]

Making close take an T: IntoRawFd would certainly prevent some occurrences of this bug. But as long as PtyMaster implements AsRawFd, it can't prevent all of them. Do you think that would confuse any nix consumers who aren't expecting close to consume an object?

Separately, I agree that making most Nix functions accept an T: AsRawFd instead of a RawFd would be a great idea.

[Susurrus]

I think we might want to explicitly address this situation in the docs for close, yes. But also when dealing with this stuff the user needs to be careful in general, and there's only so much hand-holding we can do.

Cool, I'll file a PR for the AsRawFd stuff. It'll be a nice ergonomics win I'd like to get in the next release.

[Susurrus]

Regarding the AsRawFd/IntoRawFd stuff, this doesn't have very good ergonomics because RawFd doesn't implement either of these traits. It was originally merged by @Mic92 in rust-lang/rust#40482 and then quickly reverted in rust-lang/rust#41035 because RawFd is just an alias for i32, so it would have implemented these for that which would've been bad. I'm going to file another ticket with upstream to see what can be done about this.

[asomers]

Good find. Sounds like a case for a NewType!