Linux权限管理需按执行主体与操作边界分级：服务账户限最小路径权限且禁登录；运维用sudo按角色限制命令；开发通过ACL隔离共享目录并禁敏感路径访问。
Linux用户与组权限模型怎么对应实际管理需求
Linux的rwx权限本质是三组独立控制：属主（user）、属组（group）、其他（others）。但真实运维中，直接靠chown和chmod硬配容易失控——比如把/var/www设成777图省事，结果Web进程以www-data运行，却让开发能删日志、运维无法审计变更。
真正可行的分级不是“高/中/低”，而是按**执行主体**和**操作边界**切分：
-
系统服务账户（如
nginx、mysql）：仅赋予最小必要路径的r-x或rw-，禁止登录（/sbin/nologin），不加入任何业务组 -
运维人员：用
sudo限制命令范围，禁用sudo su -，通过/etc/sudoers.d/按角色拆分（如db-admin只允许systemctl restart mysql） - 开发人员：分配独立
dev组，共享/home/dev-shared，但禁止访问/etc、/var/log等敏感路径
ACL比传统ugo权限更可控的三个场景
当chmod 750不够用时，setfacl才是解法。它不破坏原有属主/属组逻辑，还能叠加多组规则。
典型适用情况：
- 多个部门共用一个目录，但各自子目录需独立管理（如
/srv/project下frontend/归fe-team，backend/归be-team） - 临时授权某人读取日志：
setfacl -m u:alice:r /var/log/app.log，事后setfacl -x u:alice /var/log/app.log即可清除，不留痕迹 - 继承式权限：对目录加
-d参数，新创建文件自动继承ACL，避免每次touch后手动chmod
注意：getfacl查看时若发现mask::权限低于显式设置值（如u:alice:rwx但mask::r--），说明ACL未生效——必须先用setfacl -n重置mask，或改用chmod调高组权限来扩大mask范围。
sudoers配置里最容易被绕过的三个写法
/etc/sudoers语法松散，看似放行一个命令，实则可能打开提权通道。
这些写法看似合理，实际危险：
-
%admin ALL=(ALL) /bin/bash→ 允许启动交互shell，等于完全交出root权限 -
%deploy ALL=(ALL) /usr/bin/rsync→rsync --rsync-path="sh -i"可执行任意命令 -
%backup ALL=(ALL) /usr/bin/tar -cf /backup/*→ 路径通配符*可被利用为/backup/$(id>&2)触发命令执行
安全写法必须锁定完整参数序列：
%deploy ALL=(ALL) /usr/bin/rsync --archive --delete /src/ /dst/，且禁用shell元字符（
!、$、`）在sudo上下文中生效。
SELinux启用后为什么ls显示权限正常却报Permission denied
当ls -l显示-rw-r--r--且用户在属组内，仍被拒绝访问，大概率是SELinux策略拦截。它在传统DAC之上加了一层MAC（强制访问控制），连root都无法绕过。
快速定位步骤：
- 确认状态：
sestatus查看是否为enforcing - 查拒绝记录：
ausearch -m avc -ts recent | audit2why，输出会明确提示哪个type（如httpd_sys_content_t）不能读user_home_t - 临时调试：
setenforce 0验证是否SELinux导致；长期方案用semanage fcontext重标文件type，而非关SELinux
特别注意：restorecon只修复已定义的上下文，对自定义路径要先用semanage fcontext -a注册规则，否则下次restorecon无效。
