PHP脚本文件应设为644而非755，因其由Web服务器通过解释器读取执行，无需执行位，755反而增加被直接执行风险；上传目录需设755或750并禁用PHP解析；敏感配置文件须移出Web根目录或严格限制访问。
PHP 文件权限配错，不是功能异常就是被黑——644 和 755 不是万能公式，关键看谁在读、谁在写、谁根本不该碰。
PHP 脚本文件为什么不能设成 755？
很多开发者误以为“可执行”就得加 x 权限，但 PHP 脚本由 Web 服务器（如 Apache 的 www-data 或 Nginx 的 nginx 用户）通过解释器读取执行，不需要文件本身有执行位。设成 755 反而可能暴露风险：
- 如果服务器配置疏漏（比如 CGI 模式或错误的
AddHandler），.php文件可能被当作二进制直接执行，触发未预期行为 - 攻击者上传的恶意脚本若落在同目录下，755 权限会使其更容易被探测和调用
-
755允许组和其他人执行，但 Web 服务器进程通常只以单一用户身份运行，多余人等权限纯属冗余
正确做法是统一用 644：chmod 644 *.php。它保证所有者可编辑，Web 服务器用户（需属于文件所属组或为所有者）可读，其他人仅可读——刚好够用，不多给。
upload 目录为什么不能只设 755？
上传目录（如 uploads/）必须允许 Web 进程写入，但开放执行权限等于邀请攻击者上传并运行 Webshell。常见错误是设成 777 或没禁用 PHP 解析。
立即学习“PHP免费学习笔记（深入）”；
- 权限应设为
755或更严的750（如果 Web 用户是组成员），绝不用777 - 必须配合 Web 服务器配置禁用该目录下的 PHP 执行：Nginx 中加
location ~ \.php$ { deny all; }；Apache 中用.htaccess的php_flag engine off或主配置中<directory></directory>块限制 - 理想情况下，上传目录不应在 Web 根目录内，而应映射为别名（alias）或用符号链接指向外部路径，进一步隔离
仅改权限不堵解析入口，等于锁了门却留着窗户。
config.php 等敏感文件为什么必须移出 Web 根目录？
即使把 config.php 权限设成 600，只要它还在 /var/www/html/ 这类 Web 可访问路径下，就存在被误配置、重写规则错误或服务器模块漏洞导致源码泄露的风险。
- 最佳位置是 Web 根目录之外，例如
/var/www/config.php，再在代码中用绝对路径包含：require '/var/www/config.php'; - 若必须放在 Web 目录内，至少设为
640并确保所属组为www-data，同时 Web 服务器用户是该组成员：chown user:www-data config.php && chmod 640 config.php - 务必在 Web 服务器层屏蔽直接访问：
location ~ ^/config\.php$ { return 403; }（Nginx）
权限控制是最后一道防线，路径隔离才是第一道。
docker 部署 FrankenPHP 时，chown 和 setcap 怎么配合？
Docker 容器里非 root 运行 FrankenPHP，既要让进程能绑定 80/443，又要确保它能读写自己的配置与数据目录——这两件事不能靠提升用户权限解决，得拆开处理。
-
setcap CAP_NET_BIND_SERVICE=+eip /usr/local/bin/frankenphp是唯一安全方式，让二进制文件获得绑定特权端口能力，而无需root身份 -
chown -R nonroot:nonroot /config/caddy /data/caddy必须在构建镜像时完成，确保容器启动后这些路径对运行用户可读写 - 千万别在
ENTRYPOINT或启动脚本里动态chown，Docker 卷挂载后权限可能失效；也别用USER root临时提权再降权——这违背最小权限原则
容器里没有“sudo”，靠的是构建时固化权限 + 二进制能力授权，少一步都可能启动失败或权限拒绝。
