核心思路是用chown锚定Nginx日志目录归属，再用ACL精准授权多团队访问权限；必须确保Nginx进程用户（如nginx或www-data）为目录所有者或所属组成员，否则写入失败，这是ACL生效前提。
核心思路是：用 chown 锚定日志目录的归属主体，再用 ACL 精准放行多个开发团队的访问权限，避免改组、加用户或关SELinux等高风险操作。
明确Nginx日志目录的归属主体
Nginx进程（如 nginx 或 www-data）必须是日志目录的“所有者”或“所属组成员”，否则连基本写入都失败。这不是可选步骤，而是ACL生效的前提。
- 查当前Nginx运行用户：
ps aux | grep nginx | grep -v grep | awk '{print $1}' - 设日志根目录归属（以
/var/log/nginx为例）：sudo chown nginx:nginx /var/log/nginx - 确保目录权限允许组写入（因为后续ACL会基于组扩展）：
sudo chmod 775 /var/log/nginx
为各开发团队配置独立ACL规则
传统 chmod 只能设一个组，而 ACL 允许你同时给 dev-team-a、dev-team-b、ops-team 等多个组赋予不同权限，且互不干扰。
- 给开发组 A 读写日志文件（不含删除）：
sudo setfacl -m g:dev-team-a:rw- /var/log/nginx - 给运维组只读 + 进入目录权限：
sudo setfacl -m g:ops-team:r-x /var/log/nginx - 禁止实习生组删除或覆盖：
sudo setfacl -m g:interns:r-- /var/log/nginx - 设默认ACL，让新生成的日志文件自动继承上述权限：
sudo setfacl -d -m g:dev-team-a:rw- /var/log/nginx
验证与持续防护
ACL不是一次设置就一劳永逸，需确认是否生效，并防止被其他工具意外清除。
- 查看当前ACL设置：
getfacl /var/log/nginx—— 输出中应含user::rwx、group::rwx、group:dev-team-a:rw-等条目 - 测试某开发成员能否写入：
sudo -u dev-user1 touch /var/log/nginx/test.log（成功即表示ACL已通） - 避免日志轮转（logrotate）重置ACL：在
/etc/logrotate.d/nginx中添加create 664 nginx nginx并追加su nginx nginx，再加一行postrotate setfacl --restore=/etc/acl.nginx.log.bak endscript，并提前用getfacl /var/log/nginx > /etc/acl.nginx.log.bak备份
为什么不用单纯改组或加sudo？
把多个开发成员全加进 nginx 组，等于授予他们对整个 Nginx 运行环境的潜在控制权（比如误删 conf、重启服务）；而给 sudo 权限更违背最小权限原则。ACL 在不提升用户系统级权限的前提下，仅开放日志路径的受控访问，真正实现“权限按需下发、边界清晰可见”。
