nginx权限分离是底层安全设计原则：master必须以root绑定端口、读配置、建监听套接字后休眠；worker必须通过user指令降权运行，处理请求时无root权限，依赖内核机制与配置协同保障隔离。
Nginx 多进程架构中，权限分离不是附加功能，而是稳定性和安全性的底层设计原则。核心就一点：主进程用 root 做事，工作进程用普通用户干活——各守其界，互不越权。
Master 进程为什么必须用 root 权限？
它要完成三件非 root 不可的事：
- 绑定 1024 以下端口（如 80、443），Linux 系统强制要求这类端口只能由 root 或具备 CAP_NET_BIND_SERVICE 能力的进程绑定
- 读取全局配置文件（比如 /etc/nginx/nginx.conf），该文件通常属主为 root，权限为 644，普通用户可读但不能随意修改
- 创建监听 socket 并将其句柄安全地传递给 Worker，这个过程发生在 fork 之前，需要 root 才能完成 bind() 和 listen()
注意：Master 启动后并不会长期保持高权限执行逻辑；它做完初始化就进入休眠，只响应信号，不参与网络 I/O，本身攻击面极小。
Worker 进程为何必须降权运行？
这是最关键的安全防线。Worker 处理所有外部请求，直接暴露在互联网流量中，一旦被利用（如正则回溯、内存越界、模块漏洞），低权限能大幅限制破坏范围：
- 通过 user 指令指定运行用户（例如
user nginx;或user www-data;），Nginx 启动时会主动调用 setuid()/setgid() 降权 - 降权后，Worker 无法写入系统关键路径（如 /etc、/root）、无法加载内核模块、无法绑定特权端口，甚至无法读取其他用户的敏感文件
- 即使某个 Worker 因恶意请求崩溃或被劫持，攻击者也只能在 nginx 用户上下文中活动，无法提权或横向渗透
若未配置 user 指令，Nginx 默认以 nobody 用户运行，但建议显式声明并确保该用户存在、无 shell（/sbin/nologin）、且仅对所需目录有最小读/执行权限。
权限边界如何被实际维护？
权限隔离不是靠自觉，而是靠内核机制和 Nginx 自身行为共同保障：
- Master 在 fork Worker 前已准备好监听 socket，并通过文件描述符继承方式交给子进程——Worker 无需再 bind，也就无需 root 权限
- Worker 进程启动后立即丢弃 root capability（Linux 下调用 cap_drop_all()），彻底失去提权能力
- 配置中涉及的路径（如 root 目录、日志路径、临时文件目录）必须对 Worker 用户可读/可写，否则会出现 403 或启动失败；可用
chown -R nginx:nginx /var/log/nginx /var/cache/nginx统一授权 - SELinux 或 AppArmor 等强制访问控制策略可进一步收紧 Worker 的文件访问、网络连接和进程操作范围，弥补传统 DAC 的不足
常见权限误配置与修复提示
几个高频踩坑点：
-
配置了 user，但对应用户不存在或 home 目录不可访问 → 启动报错 “getpwnam() failed”；需先创建用户：
useradd -r -s /sbin/nologin nginx -
日志目录属主是 root，Worker 无法写入 → error.log 报 “open() “/var/log/nginx/error.log” failed (13: Permission denied)”；执行
chown nginx:nginx /var/log/nginx - 静态文件目录权限太严（如 600） → 返回 403；应设为 644（文件）和 755（目录），且属主为 Worker 用户
-
启用了 proxy_cache 或 fastcgi_cache，但缓存路径未授权 → 缓存失效或写入失败；确保
proxy_cache_path指向的目录由 nginx 用户拥有
