今天要敲的
$ id # 我是谁，在哪些组
$ groups root
$ sudo chown root:root /tmp/lab/t.txt
$ sudo chown -R nginx:nginx /usr/share/nginx/html
$ sudo chgrp wheel /tmp/lab/t.txt系统怎么决定放不放行
把昨天和今天连起来
你访问一个文件时，系统依次问三个问题
- 1 · 你是属主吗
- 是 → 只看属主那三位，判断结束，后面两组跟你无关。
- 2 · 你在属组里吗
- 是 → 只看属组那三位，判断结束。
- 3 · 都不是
- 那就用其他人那三位。
所以光看权限位是不够的——你得先知道自己是谁。这就是 id 的作用。
id 和 groups
先搞清楚自己的身份
看自己
$ id
uid=1000(devops) gid=1000(devops) groups=1000(devops),10(wheel)
↑ 用户ID ↑ 主组 ↑ 所属的全部组
$ id root
$ groups # 只看组，输出更简洁
$ whoami # 只看用户名主组 和 附加组
- 主组（gid）
- 建用户时自动创建的同名组。你新建的文件，属组默认就是它。一个用户只有一个主组。
- 附加组（groups）
- 额外加入的组，可以有很多个。用来获得额外权限——比如加进
wheel组就能用 sudo。
chown
改属主和属组
三种写法
$ sudo chown nginx f.txt # 只改属主
$ sudo chown nginx:nginx f.txt # 属主和属组一起改（最常用）
$ sudo chown :nginx f.txt # 只改属组（等于 chgrp）
$ sudo chown -R nginx:nginx /usr/share/nginx/html
↑ -R 递归，整个目录树都改。部署网站时的标准动作为什么 chown 需要 sudo
因为普通用户不能把自己的文件送给别人——否则就能绕过磁盘配额，或者栽赃别人。只有 root 能改属主。
但改属组是可以的：如果你本来就在那个组里，chgrp 自己的文件不需要 sudo。
实战：网站报 403
今天最值钱的一节
这是运维最经典的场景之一，面试也常问。网站打不开报 403 Forbidden，原因几乎总在这三层里，而且要按顺序查：
403 的标准排查顺序
- 第一层 · 属主属组
- 网页目录的属主，是不是运行 nginx 的那个用户？
ps aux | grep nginx看它以谁的身份跑，ls -ld /usr/share/nginx/html看目录归谁。 - 第二层 · 权限位
- 目录有没有 x（进得去），文件有没有 r（读得了）。
昨天讲的：目录缺 x，里面的文件一个都访问不了。 - 第三层 · SELinux
- 前两层都对却还是 403，八成是它。第 19 天专门讲。
先用ls -Z看安全上下文，或者sudo setenforce 0临时关掉试一下。
一次完整排查
# 1. nginx 以什么身份在跑
$ ps aux | grep nginx | head -2
nginx 2841 ... nginx: worker process
↑ 是 nginx 这个用户
# 2. 网页目录归谁、权限多少
$ ls -ld /usr/share/nginx/html
drwxr-xr-x. 2 root root 4096 Sep 7 10:00 /usr/share/nginx/html
↑ 属于 root，但其他人有 r-x，所以 nginx 能进能读 —— 这层没问题
# 3. 具体文件呢
$ ls -l /usr/share/nginx/html/index.html
-rw-------. 1 root root 612 Sep 7 10:00 index.html
↑ 600！其他人一点权限都没有 —— 问题在这
# 4. 修
$ sudo chmod 644 /usr/share/nginx/html/index.html为什么"有顺序"这件事重要
面试问 403 怎么查，能说出「先看属主权限、再看 SELinux」这个顺序的人，比只说一个原因的人强得多。
因为运维的核心能力不是知道答案，是有章法地逼近答案。
一个常见误区
改属主还是改权限
发现某个服务读不了文件，有两条路：把文件属主改成那个服务，或者放开其他人的权限。
该选哪个
- 改属主 ✅
chown nginx:nginx——精确授权，只有 nginx 能动，别人还是碰不到。优先用这个。- 放开权限 ⚠️
chmod 777——所有人都能改。这是偷懒，问题是解决了，但门也全开了。
今天的面试点
「网站报 403 怎么排查？」
「先看目录和文件的属主权限，确认运行服务的那个用户（比如 nginx）能进能读；再看 SELinux 的上下文；最后才看配置里的路径写没写对。」
关键是说出顺序。有排查路径的回答，永远比罗列可能原因强。
「服务读不了文件，你怎么处理？」
「优先用 chown 把属主改成那个服务用户，精确授权；而不是 chmod 777 把门全开。」
今天的练习
敲完再走 · 约 12 分钟
id看自己的 uid、主组、附加组，再id root对比touch /tmp/lab/own.txt，ls -l看新文件的属主属组是不是你自己sudo chown root:root /tmp/lab/own.txt，再ls -l看变化，然后试着echo x >> /tmp/lab/own.txt看会不会被拒- 模拟 403：
sudo chmod 600 /tmp/lab/own.txt，用普通用户cat它，看拒绝信息，再按「先ls -l看权限 →id看身份」的顺序自己分析一遍 - 把它改回能读：想想该用
chown还是chmod，为什么
明天预告
Day 08 讲建用户、改密码、锁账号，还有 /etc/passwd、/etc/shadow 这几个文件里到底存了什么。