acl 与 chown 联合管理多团队日志目录的核心是“归属定边界、acl 做细分”：chown 锚定属组（如 logadmin）并启用 sgid，chmod 设置基础组权限，再用 setfacl 按角色（ops/dev/audit）精细化授权，必须设默认 acl 并注意 mask 和用户显式授权。
用 ACL 和 chown 联合管理多团队共享日志目录，核心是“归属定边界、ACL 做细分”——chown 确保目录有明确且安全的属主/属组结构，ACL 在此基础上叠加角色级权限，避免传统权限模型下因强行共用组导致的越权或权限不足。
先用 chown 锚定基础归属与 SGID 机制
日志目录（如 /var/log/app）不能直接开放给所有团队用户修改属主，而应由运维统一管控：
- 将目录属组设为一个专用协作组，例如
logadmin：sudo chown :logadmin /var/log/app - 启用 SGID 位，确保所有新生成的日志文件、子目录自动继承
logadmin组：sudo chmod g+s /var/log/app - 赋予组基本可操作权限（注意：大写
X避免误加执行权到普通日志文件）：sudo chmod g+rwX /var/log/app
再用 ACL 实现多团队差异化访问
假设三个团队角色：运维（ops）、开发（dev）、审计（audit），需求分别是“全读写删”、“只读最新日志”、“只读归档日志”。ACL 可精准满足：
- 运维团队需完全管理：
sudo setfacl -R -m g:ops:rwx /var/log/app - 开发团队仅读取活跃日志（如
current/子目录），禁止删改：sudo setfacl -R -m g:dev:r-x /var/log/app/current/ - 审计团队只读压缩归档（
archive/*.gz），且不能遍历其他目录：sudo setfacl -m u:audit:r-- /var/log/app/archive/*.gz
必须设置默认 ACL，防止新日志文件失效
日志轮转（logrotate）或应用新写入的日志文件，默认不继承 ACL。漏掉这步，新文件就只剩基础组权限，极易引发“开发突然看不到日志”类问题：
- 对整个共享目录设置默认 ACL（影响后续新建项）：
sudo setfacl -d -m g:ops:rwx,g:dev:r-x /var/log/app - 若日志服务以
syslog或www-data用户运行，还需显式授权该用户读写权：sudo setfacl -m u:syslog:rw- /var/log/app
关键避坑提醒
联合使用时最容易出错的几个点：
-
不要用 chmod 直接覆盖 ACL 权限：比如
chmod 750 /var/log/app会清空所有 ACL 条目；要用setfacl -b显式清除，再重新设 -
mask 决定 ACL 实际生效上限：当执行
setfacl -m g:dev:r-x后，若 mask 是r--，那r-x实际只生效r--；可用setfacl -n -m m:rwx手动提升 mask - 审计团队若需跨目录读取，优先用 ACL 而非加进 logadmin 组：否则审计人员也能删改实时日志，违背最小权限原则
