c - mkstemp() - 关闭描述符并再次重新打开它是否安全？

Question

当使用 mkstemp() 生成临时文件名时，立即对 mkstemp() 返回的文件描述符调用 close() 是否安全，将 mkstemp() 生成的文件名存储在某处并使用它(在很多情况下)稍后)再次打开文件以写入临时文件？或者这个临时文件名是否会在我调用 close() 后立即再次可用？

我问的原因是我想知道为什么 mkstemp() 会返回一个文件描述符。如果立即 close() 描述符是安全的，为什么它会返回一个描述符呢？ mkstemp() 可以自行关闭它并给我一个文件名。

Answer 1

没有。在您使用 mkstemp() 创建文件和您重新打开它的时间之间，您的对手可能已经删除了您创建的文件并在其位置放置了一个指向其他地方的符号链接(symbolic link).这是一个 TOCTOU(检查时间，使用时间)漏洞，如果您保持文件描述符打开，使用 mkstemp() 可以在很大程度上避免该漏洞。

一旦您关闭文件描述符，所有的赌注都会在一个充满敌意的环境中落空。

请注意，即使您保持文件描述符处于打开状态，对手也可能会删除文件或重命名文件，然后在其位置创建自己的文件(符号链接(symbolic link)、目录)。文件描述符仍然有效。您可以使用 stat() 获取名称信息，使用 fstat() 获取文件描述符信息，如果两者匹配 (st_dev 和 st_ino 字段)，那么您可能还可以。如果他们不同，则有人找到了该文件 — 如果您重命名它，您可能正在重命名他们的文件，而不是您创建的文件。

虽然最初由 mkstemp() 创建的文件仍然存在，但不会重新生成名称。通常，连续调用 mkstemp() 无论如何都会创建不同的名称，但名称在创建时保证是唯一的(请参阅 open() 的 O_EXCL 标志) .

以防万一你想知道，不——没有办法将名称与文件描述符相关联(没有假设的int flink(int fd, const char *name) 系统调用)。前一段时间在 Stack Exchange 的一个网站上有一个关于这个的问题，答案肯定是否定的，引用了 Linux 内核邮件列表等等。一个这样的问题是 Is it possible to recreate a file from an opened file descriptor? ，但我认为这个问题还有一个更彻底的版本。