主页 / unix / 问题 / 673641
Accepted
cas
Asked: 2021-10-18 20:06:44 +0800 CST

/proc/*/cmdline 是世界可读的有什么原因吗？

  • 772

也许我今天还没有喝足够的咖啡，但我不记得或想不出为什么/proc/PID/cmdline应该是世界可读的——毕竟，/proc/PID/environ不是。

使其只能由用户（当然也可能是组和 root）可读，可以防止作为命令行参数输入的密码被随意暴露。

当然，它会影响其他用户的运行ps等等htop——但这是一件好事，对吧？那将是不使其具有世界可读性的关键。

linux permissions

2 个回答

  1. Best Answer

    我怀疑主要的，也许唯一的原因是历史原因——/proc/.../cmdline最初是世界可读的，所以为了向后兼容，它仍然是这样。cmdline在 1992 年 12 月 2 日发布的 0.98.6 中添加，模式为 444；变更日志说

         - /proc filesystem extensions.  Based on ideas (and some code) by
       Darren Senn, but mostly written by yours truly.  More about that
       later.

    我不知道“后来”是什么时候；据我所知，Darren Senn 的想法已经消失在时间的迷雾中。

    environ是向后兼容性论点的一个有趣的反例：它一开始是文字可读的，但在 1.1.85 中只有它的所有者才可读。我还没有找到更改日志，所以我不知道原因是什么。

    /proc/${pid}（包括）的整体可访问性和可见性/proc/${pid}/cmdline可以使用prochidepid3.3 版内核中添加的mount 选项来控制。gidmount 选项可用于授予对特定组的完全访问权限，例如，监视进程仍可以看到所有内容，而无需以 root 身份运行。

    • 36

  2. 进程的命令行一直被认为是 Unix 中的公共信息，并且始终可以通过ps(1)命令获得。相反，一个过程的环境从来就不是这样的公开信息。

    在最初的 Unix 实现中，ps是一个 setuid 可执行文件，它/dev/mem以调试器的方式直接从内核的活动内存中打开和提取所有信息。/procLinux从早期就支持类似 plan9 的文件系统，并且ps被实现为一个简单的非 setuid程序，它只是打开和读取文件/proc/<pid>/stat，如/proc/<pid>/cmdline. 由于它们既是用于获取该信息的常规内核/用户界面，也是作为解析ps(yuck) 输出的 shell 友好替代方案，因此它们不可能，而且比ps.

    当然，它会影响其他用户的运行ps等等htop——但这是一件好事，对吧？那将是不使其具有世界可读性的关键。

    不，这不是一件好事。除了打破标准（参见上面的链接），这将使系统在没有 root 权限的情况下无法调试，其安全优势充其量只是虚幻的。（请注意，在 Unix 发明的时候，通过默默无闻和言论自由限制的安全性还没有像今天这样流行。）

    您不必想象这样的 Linux 系统会是什么样子——hidepid对于实际用户来说，已经有 Android 的非 root 系统是一个讨厌的黑盒子（以所有可能的方式锁定，而不仅仅是使用 ） ，但对外部攻击者和数据收集者的抵抗力丝毫不亚于典型的 Debian 或 Slackware 桌面或服务器。

    • 23

相关问题