`close` _ignores_ EBADF (`.badFileDescriptor`) which is super dangerous, needs to preconditionFailure this

[weissi]

swift-subprocess/Sources/Subprocess/Configuration.swift

Lines 829 to 831 in c0bbfa5

	if errno != .badFileDescriptor {
	throw errno
	}

This is an extremely dangerous line of code. If you every hit EBADF on close then you know all bets are off and the only thing you should do is crash. Why so extreme? If some piece of code lost track of the file descriptors and closed 'the wrong one', security vulnerabilities will happen.

For example:

A confused piece of code accidentally double-closes

let fd = openSomething() // A
defer {
    try? close(fd) // B
}

[...]

write(fd, "some data", ...) // C

try? close(fd) // D

this looks harmless because it looks somewhat sensible that close would be able to detect a failure to close. But that is not true on UNIX because POSIX guarantees to always use the lowest available fd number.

So the above piece of code will absolutely close an unrelated file descriptor if some other thread opens a file descriptor between point A and D which is very likely. Now it might sound kinda harmless to accidentally close an unrelated file descriptor but it's really not. This is how security vulnerabilities are made: If we closed an unrelated file descriptor a 'hole' opens up in the file descriptor table that will often promptly be filled with something else. This means that writes of sensitive data might hit unrelated network connections or files. I have personally seen a process that I worked on that has sent sensitive data means for one HTTP connection into another HTTP connection by accident. It was medical data...

[weissi]

The only correct way to handle EBADF is to preconditionFailure("hit EBADF -- something closed owned file descriptor \(fd)"). See SwiftNIO code which handles that correctly.