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/

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无效。

# mysql  # 多个  # 才是  # 还能  # 自定义  # 要先  # 它在  # 而非  # 它不  # 切分  # var  # 继承  # linux  # go  # nginx  # app  # mac  # 为什么  # red  # bash  # 不留