解析/proc/file 是否安全？

/proc 是一个虚拟文件系统: 实际上，它只是提供了内核内部的一个方便视图。读取它肯定是安全的(这就是为什么它在这里) ，但从长远来看是有风险的，因为这些虚拟文件的内部可能会随着更新版本的内核而发展。

剪辑

更多信息请参阅 Linux 内核文档中的 proc 文档，第1.4章网络 我找不到信息是如何随着时间演变的。我以为它被冻住了，但是没有确切的答案。

编辑2

根据 斯科博士(不是 linux，但我确信所有的 * nix 风味都是这样的)

虽然进程状态和 因此/proc 的内容 文件可以从即时更改为 即时，a/proc 的单个读(2) 文件保证返回一个 “理智”的国家代表 读数是原子级的 进程状态的快照。 这种保证不适用于 应用于 a/proc 的连续读取 正在运行的进程的 除此之外，原子性是特定的 申请的输入/输出不获保证 As (地址空间)文件; 任何进程地址的内容 空间可能会同时被修改 该过程或任何其他过程的长期可持续发展计划 程序。

虽然 /proc中的文件在用户空间中显示为常规文件，但它们不是真正的文件，而是支持来自用户空间的标准文件操作的实体(open、 read、 close)。请注意，这与磁盘上有一个由内核更改的普通文件完全不同。

内核所做的就是使用类似于 sprintf的函数将其内部状态打印到自己的内存中，并且当您发出 read(2)系统调用时，该内存将被复制到用户空间中。

内核处理这些调用的方式与处理常规文件的方式完全不同，这可能意味着您将读取的数据的整个快照在 open(2)时就已经准备好了，而内核确保并发调用是一致的和原子的。我还没在别的地方读到过，但是不这样做真的没有意义。

我的建议是看一下在你的 Unix 风格中 proc 文件的实现。这实际上是一个不受标准控制的实现问题(输出的格式和内容也是如此)。

最简单的示例是在 Linux 中实现 uptime proc 文件。注意整个缓冲区是如何在提供给 single_open的回调函数中产生的。

Linux 内核中的 procfs API 提供了一个接口，以确保读取返回一致的数据。阅读 __proc_file_read中的评论。第一项)在大注释块中解释了这个界面。

也就是说，正确使用这个接口以确保返回的数据是一致的，当然取决于特定 proc 文件的实现。因此，回答你的问题: 不，内核并不保证在读取过程中 proc 文件的一致性，但是它为这些文件的实现提供了提供一致性的方法。

除了未知的 bug 之外，/proc中没有竞态条件会导致读取损坏的数据或新旧数据的混合。从这个意义上说，它是安全的。然而，仍然存在竞争条件，即从 /proc读取的大部分数据可能在生成时就已经过时，甚至在读取/处理时更是如此。例如，进程可以在任何时候死亡，一个新进程可以被分配相同的 pid; 在没有竞态条件的情况下，您可以使用的唯一进程 id 是您自己的子进程的 id。网络信息(打开端口等)和 /proc中的大部分信息也是如此。我认为，依赖于 /proc中的任何数据都是准确的，除了关于您自己的进程和可能的子进程的数据之外，这种做法是糟糕和危险的。当然，将 /proc中的其他信息呈现给用户/管理员以获得信息/日志记录等目的仍然是有用的。

我手边有 Linux 2.6.27.8的源代码，因为我目前正在一个嵌入式 ARM 目标上进行驱动程序开发。

例如，第934行的文件... linux-2.6.27.8-lpc32xx/net/ipv4/raw.c包含

    seq_printf(seq, "%4d: %08X:%04X %08X:%04X"
" %02X %08X:%08X %02X:%08lX %08X %5d %8d %lu %d %p %d\n",
i, src, srcp, dest, destp, sp->sk_state,
atomic_read(&sp->sk_wmem_alloc),
atomic_read(&sp->sk_rmem_alloc),
0, 0L, 0, sock_i_uid(sp), 0, sock_i_ino(sp),
atomic_read(&sp->sk_refcnt), sp, atomic_read(&sp->sk_drops));

输出

[wally@zenetfedora ~]$ cat /proc/net/tcp
sl  local_address rem_address   st tx_queue rx_queue tr tm->when retrnsmt   uid  timeout inode
0: 017AA8C0:0035 00000000:0000 0A 00000000:00000000 00:00000000 00000000     0        0 15160 1 f552de00 299
1: 00000000:C775 00000000:0000 0A 00000000:00000000 00:00000000 00000000     0        0 13237 1 f552ca00 299
...

在函数 raw_sock_seq_show()中，它是 环境保护署署长处理函数层次结构的一部分。直到对 /proc/net/tcp文件发出 read()请求才生成文本，这是一种合理的机制，因为 环境保护署署长读取肯定比更新信息少得多。

有些驱动程序(比如我的驱动程序)使用单个 sprintf()实现 proc _ read 函数。核心驱动程序实现的额外复杂性是处理可能非常长的输出，这些输出在单次读取期间可能不适合中间的内核空间缓冲区。

我用一个使用64K 读取缓冲区的程序测试了它，但是它在我的系统中为 proc _ read 返回数据产生了一个3072字节的内核空间缓冲区。需要多个带有前进指针的调用才能返回更多的文本。当需要多个 i/o 时，我不知道如何正确地使返回的数据保持一致。当然，/proc/net/tcp中的每个条目都是自我一致的。并排的行有可能是不同时间的快照。

当您读取/proc 文件时，内核正在调用一个事先注册的函数作为该 proc 文件的“ read”函数。参见 fs/proc/generic.c 中的 __proc_file_read函数。

因此，proc read 的安全性只有在内核调用函数来满足读请求时才是安全的。如果该函数正确地锁定了它接触的所有数据，并在缓冲区中返回给您，那么使用该函数进行读取是完全安全的。由于 proc 文件(比如用于满足对/proc/net/tcp 的读请求的 proc 文件)已经存在了一段时间，并经过了仔细的审查，因此它们是您所能要求的最安全的文件。事实上，许多常见的 Linux 实用程序依赖于从 proc 文件系统读取和以不同的方式格式化输出。(我第一时间想到的是‘ ps’和‘ netstat’这两个词)。

像往常一样，你不必相信我的话，你可以看着源头来平息你的恐惧。下面来自 proc _ net _ tcp.txt 的文档告诉您/proc/net/tcp 的“ read”函数位于何处，因此您可以查看从 proc 文件读取时运行的实际代码，并自己验证是否存在锁定危险。

本文档描述了接口 /proc/net/tcp 和/proc/net/tcp6。
请注意，这些接口是 弃用以支持 tcp _ diag。 这些/proc 接口提供有关当前活动 TCP 的信息 连接，并由 Net/ipv4/tcp _ ipv4. c 中的 tcp4 _ seq _ show () 中的 tcp6 _ seq _ show () Net/ipv6/tcp _ ipv6.c.

一般来说，没有。所以这里的大部分答案都是错误的它 也许吧是安全的，这取决于你想要什么属性。但是，如果对 /proc中文件的一致性假设太多，那么很容易在代码中出现 bug。例如，请参见 这个错误来自于假设 /proc/mounts是一个一致的快照。