acl是最稳妥方案，关键在于精准、可控、可回收：仅对指定目录（如/var/log/app-prod）设最小必要权限（r-x），用setfacl -m/u:outsourcer01:rx添加用户级acl，配合setfacl -d -m设默认acl使新文件继承；权限需人工或脚本定时回收（setfacl -x），并提前验证文件系统acl支持、selinux及挂载状态。
临时外包人员需要在指定生产目录下排查问题，又不能长期拥有写权限——这种场景下，ACL 是最稳妥的方案。关键不是“给不给权限”，而是“怎么给得精准、可控、可回收”。
明确权限范围与时间边界
ACL 本身不直接支持时间限制，但可以和系统级机制配合实现“限时效果”：
- 权限只设到具体目录（如 /var/log/app-prod），不递归到父级或敏感路径
- 仅授予最小必要权限：r-x（排查通常只需读+进入目录）；若需临时写日志或 dump 文件，才加 w，避免给 x 给可执行文件带来风险
- 不修改目录原有属主和属组，避免影响其他服务（如 nginx、app 进程仍以 www-data 运行）
用 setfacl 设置用户级 ACL
假设外包账号为 outsourcer01，目标目录为 /var/log/app-prod：
- 执行：sudo setfacl -m u:outsourcer01:rx /var/log/app-prod
- 如需让其对子目录和新生成的日志文件也生效，再加默认 ACL：sudo setfacl -d -m u:outsourcer01:rx /var/log/app-prod
- 验证：getfacl /var/log/app-prod，应看到类似 user:outsourcer01:r-x 和 default:user:outsourcer01:r-x
配套做权限回收与审计准备
ACL 权限不会自动过期，必须人工或脚本清理：
- 约定外包支持周期（例如 3 天），到期前 2 小时执行：sudo setfacl -x u:outsourcer01 /var/log/app-prod
- 为防遗漏，可提前写好回收脚本并加入定时任务（如 cron 在支持截止日次日凌晨执行）
- 同步记录操作日志：sudo journalctl -u systemd-journald --since "2026-07-19" | grep setfacl，便于事后审计
绕不开的隐藏限制要提前检查
即使 ACL 设好了，也可能被底层机制拦截：
- 确认文件系统已启用 acl：运行 mount | grep "$(df . | tail -1 | awk '{print $1}')" | grep acl，无输出需先 mount -o remount,acl /
- SELinux 若启用（sestatus 查看），可能拒绝访问，临时调试可用 sudo setenforce 0，但生产环境应配对应策略而非关闭
- 目录所在挂载点是否为只读（mount | grep ro）？若是，ACL 无效，需联系运维调整挂载参数
