服务器文件权限治理需形成可验证闭环流程，重点监控Web路径、上传目录、配置文件和日志目录四类高风险区域，通过脚本自动扫描、带回滚的修复及CI/CD源头卡控实现持续加固。

服务器文件权限的定期扫描与修复，不是“扫完就完”，而是要形成可验证、可闭环的运维动作。核心在于把权限检查纳入日常加固流程，而不是等出问题再救火。

明确哪些目录和文件必须纳入扫描

重点盯住Web服务运行路径、上传目录、配置文件、日志写入点这四类高风险区域：

• /var/www/ 及其子目录：检查所有者是否为部署用户（如deploy），组是否为www-data，权限是否符合755（目录）或644（文件）
• /var/www/upload/ 或类似上传路径：必须禁止执行权限（chmod -x），且组写权限应仅限于特定服务账户（如www-data:uploaders）
• /etc/ 下关键配置文件（如nginx.conf、my.cnf、ssh/sshd_config）：所有者应为root，组为root，权限严格控制在644或600
• /var/log/ 目录及应用日志文件：确保日志服务（如rsyslog、journald）有写权限，但普通用户不可读敏感日志（如auth.log）

用脚本+定时任务实现自动扫描

别依赖人工肉眼检查。写一个轻量级扫描脚本，每天凌晨执行：

• 用 find 命令定位异常权限：比如查找 world-writable 目录（find /var/www -type d -perm -002）、可执行的PHP文件（find /var/www -name "*.php" -perm -u+x）
• 用 ls -l 结合 awk 校验标准权限：对关键路径做白名单比对，不匹配即告警
• 结果输出到统一日志（如 /var/log/perm-scan.log），并邮件或钉钉推送高危项（如发现777目录、非root用户拥有/etc/shadow）

修复动作必须带验证和回滚能力

自动修复不是简单 chmod 一了百了，得防误操作：

• 修复前先用 stat 或 ls -ld 记录原始权限和所有者，存档保留7天
• 批量修复用 chown 和 chmod 时加 -v 参数，输出变更详情
• 对Web目录，优先用 --reference 模式同步安全模板：chmod --reference=/var/www/safe-template /var/www/html
• 修复后立即用curl或wget访问关键页面，或尝试上传测试文件，验证功能是否恢复

把权限治理嵌入发布和变更流程

很多权限问题是人为引入的。从源头卡控：

• CI/CD流水线中加入权限检查步骤：打包前校验代码目录权限，拒绝含777或.svn/.git泄露的构建包
• 运维操作必须通过sudo受限命令执行，禁止直接su -；所有chmod/chown操作自动记入auditd日志
• 新上线服务默认启用ACL隔离：比如给备份脚本单独分配读取权限，而非把整个/var/log设为755