proxy_store_access需与用户隔离、目录权限、运行用户及umask控制协同生效，仅设该指令无法保障文件安全；它只控制Nginx回源创建文件的权限位，不改变已有文件权限或目录可写性。
要让 proxy_store 落盘的文件真正安全，关键不是只开个 proxy_store_access 指令，而是从文件归属、目录权限、落盘路径隔离和运行用户四个层面协同控制。它本质是“让 Nginx 以指定权限创建文件”，但若底层目录或用户配置不当，该指令形同虚设。
明确 proxy_store_access 的作用边界
proxy_store_access 只控制 Nginx 主动创建（即回源下载并写入）的文件的权限位，不改变已有文件权限，也不影响目录本身的可写性。它有三组值：user/group/all，每组支持 r/w/rw/none。例如：
-
proxy_store_access user:rw group:rw all:rw;→ 文件属主可读写，属组可读写，其他用户也可读写（不推荐） -
proxy_store_access user:rw group:rw all:—;→ 其他用户完全无权限（推荐起点） -
proxy_store_access user:rw group:r all:—;→ 属组仅可读，更保守
注意：all:— 并非万能——如果目录本身对其他用户开放写权限，攻击者仍可能删改文件。所以必须配合目录权限收紧。
严格限定落盘目录的归属与权限
静态镜像目录（如 /data/mirror）不能放在 Web 根目录下，也不能由 root 或 www-data 直接拥有。推荐做法：
- 新建专用系统用户，如
nginx-mirror：sudo adduser --system --no-create-home --group nginx-mirror - 将镜像目录归属设为该用户：
sudo chown nginx-mirror:nginx-mirror /data/mirror - 设置目录权限为
750：sudo chmod 750 /data/mirror（属主读写执行，属组读执行，其他无权限） - Nginx 主进程仍用
www-data，但在该 location 块中用proxy_store时，实际写入由 worker 进程以www-data身份完成；因此需确保www-data是nginx-mirror组成员：sudo usermod -a -G nginx-mirror www-data
禁止自动继承危险权限，关闭 umask 干扰
Nginx worker 进程默认受系统 umask 影响（通常是 0022），可能导致 proxy_store_access 设置被削弱。应在 Nginx 启动前显式重置：
- 在 systemd service 文件（如
/etc/systemd/system/nginx.service）的[Service]段添加：UMask=0027 - 或在 Nginx 配置顶部的
http块中加：env UMASK=0027;（需确认 Nginx 编译时启用了 env 模块） - 验证方式：手动触发一次回源，然后
ls -l /data/mirror/path/to/file，确认权限为-rw-r-----类型，而非-rw-rw-r--
禁用 root 权限运行，剥离不必要的能力
即使配置了 proxy_store_access，若 Nginx 以 root 启动且未降权，一旦配置失误或模块漏洞被利用，风险极高：
- 确保
user指令已明确设置，如user www-data;，且该用户无 shell、无登录权限 - 禁用
master_process on;以外的特权操作，如避免使用load_module加载非标准模块 - 若环境允许，启用 Linux capabilities 限制：
CapabilityBoundingSet=CAP_NET_BIND_SERVICE CAP_SETUID CAP_SETGID，移除CAP_DAC_OVERRIDE等高危能力
本质上，proxy_store_access 是最后一道文件权限闸门，而前面的用户隔离、目录控制和运行态约束，才是让它真正起效的前提。
