普通用户执行ps或top看不到其他用户进程，是因为Linux内核hidepid参数（默认值2）限制/proc/<pid>目录可见性，属内核级隔离机制，非权限位或SELinux所致。
为什么普通用户执行 ps 或 top 看不到其他用户的进程？
linux 默认启用 hidepid 内核参数（自 3.3+），它控制 /proc 下进程目录的可见性。即使用户有读权限，若 hidepid=2（常见于 centos/rhel 7+/ubuntu 20.04+ 安全加固配置），非 root 用户连 /proc/<pid> 目录都列不出来，ps aux 自然只显示自己的进程。
这不是权限位（如 chmod）问题，也不是 SELinux 拦截（除非显式启用了相关策略），而是内核级进程隔离机制。
-
hidepid=0：所有用户可看全部 /proc/<pid>（默认，不安全） -
hidepid=1：用户能看到所有 pid 目录名，但只能读自己进程的详情 -
hidepid=2：用户只能看到自己和 init 的 pid 目录（最常用的安全值）
如何临时验证并绕过 hidepid 限制（仅调试用）
不要直接改生产系统，先确认当前值：
cat /proc/sys/kernel/hidepid
若为 2，可用以下方式临时绕过（需 root）来验证是否是它导致的“看不到”：
- 临时设为
1：echo 1 | sudo tee /proc/sys/kernel/hidepid - 再运行
ps -eo user,pid,comm --sort=-pid | head -10，观察是否出现其他用户进程 - 注意：该操作不持久，重启即恢复；且
hidepid=1仍无法读取他人进程的cmdline、environ等敏感字段
给指定用户授予查看其他进程的合理权限（非 root）
不推荐全局降级 hidepid，更安全的做法是用 capabilities 授予最小必要权：
- 给
ps二进制添加CAP_SYS_PTRACE能力：sudo setcap cap_sys_ptrace+ep /usr/bin/ps - 该能力允许进程对其他进程调用
ptrace(PTRACE_ATTACH)，而ps在hidepid=2下正是靠此绕过限制读取进程信息 - 注意：仅对
ps生效，top、htop等仍受限；若要一并放开，需分别加 cap（如sudo setcap cap_sys_ptrace+ep /usr/bin/top） - 风险提示：拥有
CAP_SYS_PTRACE的程序可能被用于进程注入或调试攻击，务必限制该二进制的属主和权限（如chmod 755，不可 world-writable）
性能排查时发现 ps 响应慢，和 _PROCESS 权限有关吗？
无关。ps 慢通常不是权限问题，而是因遍历 /proc 时遭遇阻塞进程（如 D 状态 uninterruptible sleep）、NFS 挂载点卡顿、或容器环境里大量僵尸进程元数据未及时清理。
快速定位方法：
- 用
strace -e trace=openat,readlink,stat /bin/ps -o pid= | head -5看卡在哪类系统调用 - 检查是否有大量
Z（zombie）进程：ps aux | awk '$8 ~ /^Z/ {print}' | wc -l - 确认
/proc是否挂载为hidepid=2并启用了gid=xxx（如sudo mount -o remount,hidepid=2,gid=procview /proc）——此时只有procview组成员才不受限，但组成员过多也会增加内核遍历开销
真正影响性能的是进程数量级和内核 procfs 实现细节，不是“有没有权限”。强行用 cap_sys_ptrace 不会提速，反而可能因额外 ptrace 检查略增开销。
