In GHC #13660 it was pointed out that GHC's file IO operations will currently accept file paths containing interior NULs (e.g. "hello\0world") with surprising results.

POSIX explicitly prohibits file paths containing interior NULs and for this reason many languages (e.g. Python, Java, Go, recenet PHP) currently reject such paths with an "invalid argument" error. I suggest that we do the same. Specifically, we should check the encoded form of the filepath for interior NULs and throw IOError {ioe_type=InvalidArgument} when such a path is found.

Similarly, we propose that Windows rejects NUL codepoints in FilePaths.

Implementation notes

Concretely, the relevant checks would be added in System.Posix.Internals.{new,with}FilePath, which are used by all IO operations on Windows and POSIX to encode FilePaths to buffers to pass to the operating system. The operations affected are primarily those implemented in terms of GHC.IO.FD.openFileWith (e.g. readFile, writeFile, openFile, appendFile, withFile) although there are others (e.g. System.Environment.ExecutablePath.realpath).

I have posted a preliminary merge request carrying out this change.

Backporting

As this issue may result in exploitable behavior in some server applications, we suggest that the CLC should consider applying this change retroactively in GHC 9.2, 9.4, and 9.6.