find命令可精确查找权限为777的目录，需用root权限执行find / -type d -perm 777 2>/dev/null，配合-ls查看详情，排除/proc等虚拟路径更精准，发现后应先分析归属与安全上下文再按最小权限原则整改。
find 命令查所有 777 权限目录
直接用 find 扫描整个文件系统是最常用也最可靠的方式。注意：必须用 root 权限运行，否则会跳过无权访问的路径并报错。
执行以下命令可列出所有权限为 777 的目录（不含文件）：
find / -type d -perm 777 2>/dev/null
说明：
-
-type d确保只匹配目录，避免把777文件也混进来 -
-perm 777是精确匹配（不是“包含”），即 owner/group/others 都必须是 rwx -
2>/dev/null屏蔽 “Permission denied” 报错，让结果干净可读
如果想同时看到权限数字和路径，加 -ls：
find / -type d -perm 777 -ls 2>/dev/null
为什么不能只用 ls -lR 或 chmod -R 777 的反向思维
有人试图用 ls -lR / | grep 'drwxrwxrwx'，这不可靠——因为 ls -l 输出的符号权限（如 drwxrwxrwx）可能被 ACL、SELinux 或挂载选项覆盖，而 -perm 777 是内核级权限位判断，更准确。
另外，chmod -R 777 是危险操作，它的“反向查找”没有意义；真正要防的是已存在的、未被发现的 777 目录，不是推导它怎么来的。
常见误判点：
- 某些容器或 CI 环境里，/tmp 下临时目录常设为
1777（带 sticky bit），find -perm 777不会匹配它，但find -perm -777（带减号）会——那是“至少含 777”，太宽泛，慎用 -
/proc、/sys这类虚拟文件系统里的目录权限是内核动态生成的，777是正常现象，无需处理
检查时必须排除的路径和例外
全盘扫描时，有些路径天生就不该被检查，强行扫反而干扰判断：
-
/proc、/sys、/dev：虚拟文件系统，权限无实际意义 -
/run、/var/run：运行时目录，部分服务会动态创建777socket 目录，属正常行为 - 容器 overlay 或 bind mount 路径（如
/var/lib/docker）：权限由容器引擎管理，不建议人工干预
推荐加排除参数，让结果聚焦在真实风险区：
find / \( -path /proc -o -path /sys -o -path /dev -o -path /run \) -prune -o -type d -perm 777 -ls 2>/dev/null
发现 777 目录后下一步做什么
找到结果不等于立刻 chmod 755。先确认三件事：
- 这个目录是谁创建的？
ls -ld /path/to/dir看owner和group，再查对应服务或用户是否真需要全局写入 - 是否被挂载了
noexec或nosuid？mount | grep $(df /path/to/dir | tail -1 | awk '{print $1}') - SELinux 是否限制了实际行为？
ls -Z /path/to/dir，若上下文是unconfined_u:object_r:default_t:s0，那777可能根本没生效
真正要改权限时，优先用最小权限原则：比如 Web 上传目录通常只需 755 + 所属组可写，而不是砍成 777 再补救。
最后提醒一句：自动扫描脚本里别硬写 find / ——生产环境跑一次可能卡住 I/O，务必加 -xdev（不跨文件系统）或限定路径前缀，比如只扫 /var/www 或 /home。
