linux文件权限需用chmod/chown硬性限制，禁用“隐藏”式防护；敏感文件设600，服务目录用chown+750；ACL支持细粒度授权；SELinux/appArmor实现进程级强制访问控制。
Linux文件权限设置：用 chmod 和 chown 控制谁能看到什么
敏感文件不能靠“藏”来保护，必须靠权限机制硬性限制。Linux 默认的 umask 常为 0022，新建文件会获得 -rw-r--r--（644），这意味着同组和其他用户都能读——这在生产环境里是高危默认值。
- 敏感配置文件（如
/etc/shadow、~/.aws/credentials）应设为600：chmod 600 ~/.aws/credentials - 可执行脚本若含密钥，需同时禁写和禁其他用户访问：
chmod 700 /opt/app/secrets.sh - 修改属主属组比改权限更稳妥，尤其对服务目录：
chown root:appadmin /etc/app/config.d/ && chmod 750 /etc/app/config.d/ - 注意：
chmod -R误用极易锁死服务，比如对整个/var/www递归设600会让 Web 服务器因无法读取 html 文件而 500 错误
ACL（访问控制列表）：需要细粒度授权时绕过传统三元组限制
当一个文件既要给运维组读取、又要给审计组只读、还不能开放给开发组时，chmod 的 user/group/others 模型就不够用了。这时得用 setfacl。
- 启用 ACL 前确认文件系统挂载时带
acl选项：mount | grep " /home " | grep acl，没看到就需重新挂载或改
/etc/fstab - 给特定用户加读权限（不改动原属主）：
setfacl -m u:auditor:r /etc/app/secrets.yaml - 禁止某用户访问（即使他在属组里）：
setfacl -m u:devuser:--- /etc/app/secrets.yaml - ACL 权限优先级高于传统权限，但
ls -l结尾的+容易被忽略，务必用getfacl /path确认实际生效规则
SELinux 或 AppArmor：进程级强制访问控制，防程序越权读取
普通权限只能拦住“人”，拦不住被入侵的进程。比如 Web 服务进程被 RCE 利用后，它仍能按自身 UID 读取同用户下其他文件。SELinux（RHEL/centos）或 AppArmor（ubuntu/debian）能定义“nginx 只能读 /var/www，禁止访问 /root 或 /etc/shadow”。
- 检查是否启用：
sestatus（SELinux）或
aa-status（AppArmor）
- 临时切换到宽容模式排查策略冲突：
sudo setenforce 0（SELinux），但上线前必须关回
1 - 自定义策略要先用
audit2why分析拒绝日志，再用audit2allow生成规则，直接手写容易漏掉隐式依赖（如read之前可能需要open或getattr） - 容器环境别依赖宿主机 SELinux：docker 默认禁用，kubernetes Pod 需显式设
securityContext.seLinuxOptions
隐藏文件不是安全措施：.env、.git 这类文件照样会被读取
很多团队把密钥塞进 .env 或 .git/config 就以为安全了，这是严重误解。点开头的文件只是 ls 默认不显示，cat .env、find /app -name ".env"、甚至 Web 服务器配置错误导致源码泄露时，它们全都会裸奔。
-
.env文件必须配合应用框架的加载逻辑使用，且部署时确保其不在 Web 根目录下（nginx 中用location ~ /.env { deny all; }是补救，不是替代） -
.git目录若被暴露，攻击者能直接下载全部历史提交，包括曾经删掉的密钥——用git secrets预检 + CI 拦截比事后删记录可靠得多 - 临时文件风险常被忽视：
/tmp下的config.XXXXXX若未设mkstemp()或权限，可能被同主机其他用户cat到 - 最稳妥的做法：敏感数据不落地。用
systemd的EnvironmentFile=指向/run/secrets/（tmpfs），或通过 Vault 动态注入
实际配置中，chmod 和 chown 是基础，ACL 解决协作场景，SELinux/AppArmor 应对纵深防御需求，而所有“隐藏”“重命名”“放子目录”的做法都不可信——Linux 权限模型从不关心文件名，只认 inode 和策略规则。