What is the security risk with `NamedTempFile`?

1

From the tempfiles docs:

Security

Most operating systems employ temporary file cleaners to delete old temporary files. Unfortunately these temporary file cleaners don’t always reliably detect whether the temporary file is still being used.

Specifically, the following sequence of events can happen:

  1. A user creates a temporary file with NamedTempFile::new().
  2. Time passes.
  3. The temporary file cleaner deletes (unlinks) the temporary file from the filesystem.
  4. Some other program creates a new file to replace this deleted temporary file.
  5. The user tries to re-open the temporary file (in the same program or in a different program) by path. Unfortunately, they’ll end up opening the file created by the other program, not the original file.

I'm inferring that the attack here is that some user creates their own temp file which could make your program do something malicious when it reads it.

How is the fact that operating systems can delete in-use temp files the root cause of this? Can another program on the system not just delete and replace a temp file while it's in use? Or even overwrite data without deleting and replacing the file?

For that matter, how is this any more risky than reading from the filesystem in general, not just a temporary file?

2

Maybe I can see a unique security risk if the directory temp files are being made in is world-writable. Then a different, malicious user won't be able to do anything with my temp file unless and until the operating system deletes it, after which they can create a new identically named one and do anything with it. Is this the risk?

This wouldn't change the fact that malicious programs running as your user could still do malicious things.

3

That's typical on unix (/tmp).

Let's say you have a typical system with two typical users A and B, using a shared temporary path, as is common on unix systems. A doesn't have permission to open or overwrite B's temp files unless B grants that permission. A doesn't have permission to delete B's temp files at all (due to the "restriction deletion" flag). But A does have permission to create new files in the shared path.

So if some (privileged) process comes along and deletes B's temp file, A can create a new one with the same name and with permissions such that B can open it.

4

That makes sense. It seems like the proper solution is that operating systems should have per-user /tmp directories, right?

5

Yes, but to implement it one would need to invent a time machine and go back in time half-century.

6

One more reason to be a Unix hater.

I see that the docs mention that macOS and Windows have per-user /tmp directories. So this implies that NamedTempFile is safe on those platforms?

7

Also keep in mind that the tempdir crate makes use of the TMPDIR environment variable if set, so users are always free to redirect their temporary space somewhere outside of /tmp/ if they decide to.

9

In addition to TMPDIR, there's also XDG_RUNTIME_DIR which is per-user and more appropriate for some use cases. Rust itself doesn't obey the xdg spec (kind of a problem for users who mount /tmp noexec) but you can use the xdg crate in applications.

10

You could hardly consider all processes running as a single user to be mutually trusting on most desktop platforms. This is one thing that the mobile phone OSes got right: running each application as a separate sandboxes user.

(This is especially true on the closed source OSes where many programs will also be closed source. And even if you assume programs are not malicious, which for this context seems fair[1], bugs can lead to all sorts of issues.)

  1. They are far more likely to attempt to steal your data than to actively attack other applications. ↩︎