Shirone

权限三元组#

ls -l 输出的 -rw-r--r-- 分四段：文件类型 + 属主权限 + 属组权限 + 其他人权限。文件和目录上，同样字母含义不同：

最容易误判的是目录的 x 权限：文件本身可读，但路径上任何一级目录没有 x，照样打不开。用 namei -l /srv/app/data/config.yml 可以把路径逐级权限一次列出来，是排查权限问题的首选命令。

另一个反直觉点：删除文件看的是父目录的 w+x，与文件本身是否可写无关。这就是为什么 /tmp 里自己的文件能被自己删掉，而 sticky bit（t）又阻止你删别人的文件。

数字与归属#

r=4, w=2, x=1 按位相加：644 = 属主读写、组内只读、其他人只读；755 = 属主全权、其他人可读可进入。修改归属需要管理员权限：

1
chmod 640 report.txt        # 或 chmod u=rw,g=r,o= report.txt
2
chown alice:project report.txt

umask：新文件的默认权限#

程序创建文件时会声明一个期望权限（普通文件通常 666，目录 777），umask 负责屏蔽其中部分位：umask 为 022 时，新文件是 644、新目录是 755。注意它是按位掩码，不是算术减法——umask 011 作用于 666 得到的是 666 而非 655（奇数位本来就没有执行位可减）。

umask 命令查看当前值。改 umask 只影响之后创建的文件，已有文件不受影响。

实战：配置团队共享目录#

目标：project 组的成员都能在 /srv/project 里协作，新建文件自动继承组归属，组内成员默认可互相修改。

1
sudo groupadd -f project
2
sudo usermod -aG project alice      # 把成员加入组（重新登录生效）
3
sudo mkdir -p /srv/project
4
sudo chown root:project /srv/project
5
sudo chmod 2775 /srv/project
6
sudo setfacl -d -m g:project:rwx /srv/project

逐条解释：

1. 2775 中的 2 是 SGID 位：目录带 SGID 后，其中新建的文件和子目录自动继承 project 组，而不是创建者的私人主组——这是共享目录的关键。
2. 默认 ACL（-d）：仅靠 SGID 只解决「组归属」，不解决「组内可写」——如果成员的 umask 是 022，新文件的组权限仍没有 w。默认 ACL 强制组内新建对象带 rwx，绕开各成员 umask 不一致的问题。
3. 成员加组后需要重新登录，已有终端会话里的组列表不会自动刷新。

验证：两名成员各自 touch 一个文件，互相 getfacl 确认 effective 权限含 w，再交叉修改一次。

权限排查决策表#

sudo 的最小授权原则#

能用到组权限解决的共享问题，就不要发 sudo。确实需要授权时，用 visudo -f /etc/sudoers.d/team 写只覆盖必要命令的规则，例如只允许重启指定服务：

1
%project ALL=(root) /usr/bin/systemctl restart myapp

允许 sudo vim、sudo bash 或执行用户可写的脚本，等于把整个 root 交出去。

延伸阅读#

• GNU Coreutils：File permissions
• man 5 acl、man 1 namei、man 5 sudoers