有一个在root用户下运行的进程。
ps aux | grep ProcessX root 11565 0.0 0.7 82120 22976 ? Ssl 14:57 0:02 ProcessX 现在ls -l /proc/11565/ （pid）给出了这个结果。
total 0 dr-xr-xr-x 2 root root 0 Aug 9 16:06 attr -rw-r--r-- 1 root root 0 Aug 9 16:06 autogroup -r-------- 1 root root 0 Aug 9 16:06 auxv -r--r--r-- 1 root root 0 Aug 9 16:06 cgroup --w------- 1 root root 0 Aug 9 16:06 clear_refs -r--r--r-- 1 root root 0 Aug 9 16:06 cmdline -rw-r--r-- 1 root root 0 Aug 9 16:06 coredump_filter -r--r--r-- 1 root root 0 Aug 9 16:06 cpuset lrwxrwxrwx 1 root root 0 Aug 9 16:06 cwd -> /usr/local/bin -r-------- 1 root root 0 Aug 9 16:06 environ lrwxrwxrwx 1 root root 0 Aug 9 16:06 exe -> /usr/local/bin/ProcessX dr-x------ 2 root root 0 Aug 9 16:06 fd dr-x------ 2 root root 0 Aug 9 16:06 fdinfo -r-------- 1 root root 0 Aug 9 16:06 io -rw------- 1 root root 0 Aug 9 16:06 limits -rw-r--r-- 1 root root 0 Aug 9 16:06 loginuid -r--r--r-- 1 root root 0 Aug 9 16:06 maps -rw------- 1 root root 0 Aug 9 16:06 mem -r--r--r-- 1 root root 0 Aug 9 16:06 mountinfo -r--r--r-- 1 root root 0 Aug 9 16:06 mounts -r-------- 1 root root 0 Aug 9 16:06 mountstats dr-xr-xr-x 6 root root 0 Aug 9 16:06 net -r--r--r-- 1 root root 0 Aug 9 16:06 numa_maps -rw-r--r-- 1 root root 0 Aug 9 16:06 oom_adj -r--r--r-- 1 root root 0 Aug 9 16:06 oom_score -rw-r--r-- 1 root root 0 Aug 9 16:06 oom_score_adj -r--r--r-- 1 root root 0 Aug 9 16:06 pagemap -r--r--r-- 1 root root 0 Aug 9 16:06 personality lrwxrwxrwx 1 root root 0 Aug 9 16:06 root -> / -rw-r--r-- 1 root root 0 Aug 9 16:06 sched -r--r--r-- 1 root root 0 Aug 9 16:06 schedstat -r--r--r-- 1 root root 0 Aug 9 16:06 sessionid -r--r--r-- 1 root root 0 Aug 9 16:06 smaps -r--r--r-- 1 root root 0 Aug 9 16:06 stack -r--r--r-- 1 root root 0 Aug 9 16:06 stat -r--r--r-- 1 root root 0 Aug 9 16:06 statm -r--r--r-- 1 root root 0 Aug 9 16:06 status -r--r--r-- 1 root root 0 Aug 9 16:06 syscall dr-xr-xr-x 6 root root 0 Aug 9 16:06 task -r--r--r-- 1 root root 0 Aug 9 16:06 wchan
现在，状态和地图的文件权限是相同的（ -r--r--r-- ）。 但是当我用非特权（而不是root）用户发出cat /proc/11565/maps时，它给了我一个拒绝的权限。 但是对于cat /proc/11565/status ，它按照预期输出。
有什么我在这里失踪？
这是因为文件权限不是你遇到的唯一保护。
这些不仅仅是文件系统上的常规文本文件， procfs是进程内部的一个窗口，您必须通过文件权限加上其他任何保护措施。
这些地图显示了有关内存使用的潜在危险信息以及可执行代码在进程空间内的位置。 如果你看看ASLR，你会发现这是一种防止潜在的攻击者知道代码在哪里加载的方法，在procfs中的世界可读条目中显示它是没有意义的。
这种保护措施早在2007年就已经加入：
此更改在允许访问读取地图内容之前使用“ptrace_may_attach”执行检查。 为了控制这种保护，已经添加了新的旋钮/ proc / sys / kernel / maps_protect，并对proc文档进行了相应的更新。
在ptrace_may_attach() （实际上在它调用的函数之一中）包含以下代码：
if (((current->uid != task->euid) || (current->uid != task->suid) || (current->uid != task->uid) || (current->gid != task->egid) || (current->gid != task->sgid) || (current->gid != task->gid)) && !capable(CAP_SYS_PTRACE)) return -EPERM;
因此，除非拥有相同的真实用户/组ID，保存的用户/组ID和有效的用户/组ID（即没有欺骗性的setuid东西），并且它们与拥有该进程的用户/组ID相同，你不能看到这个“文件”（除非你的进程有CAP_SYS_PTRACE功能）。