Xiuno 文件权限最佳实践与安全攻略

52JinY 助手

这两天帮朋友折腾 Xiuno 论坛（老牌轻量级 BBS 程序）的时候，又踩回了“文件权限设置”这颗老雷。表面上看就是 403、500、安装卡死、上传失败这些症状，根子却多半在权限与所有权没理顺。这里把我这次处理的思路和易错点捋一遍，给后来者省点时间。

先说大方向：权限设置的目标是“最小可用”。也就是：让 Web 服务器能读取绝大多数代码文件、能写入必须写的目录（上传、缓存、日志、配置持久化），其他一律不授予写权限，减少被挂木马或被提权的机会。很多人第一反应是把根目录一把 777 搞定，问题立刻消失，但安全也随之消失。短期爽，长期遭殃。

具体到 Xiuno，常见需要写权限的地方包括：upload/（附件和头像）、tmp/ 或 runtime/ cache/（缓存）、log/（日志），以及如果你让后台在线装插件或写配置，可能还涉及到 conf/ 或 data/ 下的某些文件。不同发行包命名略有差异，原则是：实际会产生变更的目录必须可写，其余保持只读。

接着是“权限”和“所有权”的区分。很多服务器上，chmod 调到 775 还是没法写，关键是属主/属组不对。你的 PHP 可能跑在 www-data、apache、nginx 或 www 账户下，而代码是用 root 或你的登录用户拉下来的。此时正确的姿势是：把需要写的目录 chown 给 Web 账户或将其加入同组。比如常见组合是把站点目录设为用户:nginx，目录权限 775，文件 664，让 php-fpm 以 nginx 组身份运行；或干脆 upload/cache 这几处 chown 到 www-data，然后 750/640 也能稳稳跑。只要保证“谁在写，它就有写权限”，而不是“所有人都能写”。

再说数值细节。我的惯用基线是：
- 代码文件：644
- 代码目录：755
- 可写目录：775（必要时 750）
- 可写目录内新文件：664
配合 umask 002，基本就顺畅了。如果你非得在共享主机或奇怪环境里，短期用 777 来排查可以，但务必在确认路径后收紧回去。

一些平台差异也要留心。Nginx+PHP-FPM 下常见问题是 SELinux 拦截写入，看起来权限对了还是失败。这种情况下要不是给目录打 httpd_sys_rw_content_t 的标签，要不是临时 setenforce 0 验证思路，再按规范持久化上下文。还有就是容器里挂载卷的默认权限/掩码，把宿主机的 uid/gid 和容器内的 www-data 对齐，很多“灵异事件”就消失了。

另外一个坑是插件与主题。Xiuno 的老插件喜欢在插件目录里自写配置或生成临时文件，如果你把整个 plugin 目录都设成只读，它可能会报一些莫名其妙的错误。我的做法是：给插件各自的 data 子目录授权写入，而不是给整棵树放开。实在不清楚的，用 inotify 或 strace 跟一次失败请求，能看到具体写哪个路径被拒。

安全层面，再补三点。第一，禁用通过 Web 访问的可写目录执行脚本，Nginx 用 location 限制 php 执行范围或对 upload/ 这类路径加上不解析脚本的规则，Apache 则用 .htaccess Deny/RemoveHandler 来兜底。第二，日志与缓存定期清理，权限没问题但文件巨大会拖慢 IO。第三，部署后跑一次安全审计，扫描是否有 777 遗留、是否有新建但未受控的可写路径。

最后给一个落地的排查顺序：安装或升级后，先确保代码树 644/755 基线，然后列出 Xiuno 需要写的目录，逐一 chown 到 Web 账户组并设 775，清缓存重载 PHP-FPM。若仍失败，看错误日志定位路径；在启用 SELinux 的系统上检查上下文；容器环境核对 uid/gid 映射。全流程做完，基本能把“权限相关”的疑难杂症清干净。

别把权限当成玄学，它就是“谁需要做什么事”的表述。把这层关系理直了，Xiuno 跑得既轻也稳。