Linux系统篇--用户切换与文件权限

复制代码

系列文章目录
Linux系统篇--常用指令
Linux系统篇--重定向与文件操作命令
Linux系统篇--命令的来龙去脉与检索压缩
Linux系统篇--用户切换与文件权限（本篇）

前言

前三篇我们一直在跟"文件"打交道------创建、查看、搬运、打包，几乎把文件当成了自己的东西。但真实的 Linux 是多用户系统：同一台机器上可能有你、有同事、有跑服务的专用账号，还有一个权限高到能删掉整个系统的 root。

上一篇解读 ls -l 时，我们只讲了开头的 d 和 -，后面那九位 rwxr-xr-x 只是提了一句"读、写、执行"。现在必须正面回答它们了：这九位到底怎么读？谁能改文件？为什么我自己的文件，我却改不了它的属主？

本篇先讲切换身份的两套工具------su 和 sudo，再系统梳理文件的三种拥有关系、九位权限的实际含义、chmod/chown/chgrp 三把改权限的刀，最后落到两个最容易出错的规则：角色匹配只做一次、不累加 ，以及文件的属主和属组只有超级用户能改。

一、多用户与身份

1. 我是谁：id 命令

在做任何权限相关操作前，先确认自己是谁、属于哪些组：

复制代码

id
uid=1000(student) gid=1000(student) groups=1000(student),27(sudo),4(adm)

三行信息要读懂：

uid ：用户 ID，系统内部用数字识别用户，student 只是给人看的名字；
gid：主组 ID，用户创建文件时，文件的所属组默认就是这个；
groups：该用户所属的所有组（主组 + 附加组）。

其中 27(sudo) 这一项非常关键------它说明 student 在 sudo 组里，有资格使用 sudo 提权。这是 Ubuntu 安装时自动给第一个用户加上的，很多人不知道自己的提权能力其实来自这个组。

2. root 的特殊性

root 的 uid 是 0，是 Linux 中权限最高的用户：

复制代码

id
uid=0(root) gid=0(root) groups=0(root)

root 的特殊之处不在于"拥有所有权限位"，而在于它绕过权限检查 ------文件的九位权限对 root 基本不起约束作用（唯一例外是执行权限：即使是 root，也不能执行一个没有 x 位的文件）。所以 root 能删掉任何文件、改任何文件、杀掉任何进程。

正因为如此，长期用 root 登录是极不推荐的------一条手滑的命令就可能造成不可逆的后果。正确的做法是：日常用普通用户，需要时临时提权。

二、su：切换用户

su（switch user）是最传统的身份切换方式。

1. su：不带减号的切换

复制代码

su root
Password:              # 这里要输入 root 的密码

切成功后提示符会变成 #（普通用户是 $）。但注意：su 不带减号时，只切换了身份，没有切换环境。

具体表现是：

复制代码

su
pwd
/home/student          # 工作目录还是原来的
echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games

工作目录没变，环境变量还是原来那个用户的。这会导致一个很常见的坑：su 之后执行某些命令，报 command not found------因为 PATH 里没有 /sbin、/usr/sbin 这些 root 常用的目录。

2. su -：完整登录式切换

加一个减号（或 -l、--login），行为就完全不同了：

复制代码

su -
Password:
pwd
/root                  # 工作目录切到 root 的家目录
echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin

su - 会完整地以目标用户的身份重新登录一次 ：加载目标用户的 ~/.bashrc、~/.profile，重置环境变量，切换到目标用户的家目录。这才是"真正变成了那个用户"。

这个区别必须记牢：

命令	切换身份	切换环境	工作目录
`su`	是	否	保持不变
`su -`	是	是	切到目标用户家目录

排查权限问题、执行系统管理命令时，一律用 su -，可以避免大量"莫名其妙找不到命令"的困扰。

3. su 的局限：需要对方的密码

su 最大的问题是：切到 root 就必须知道 root 的密码。

而 Ubuntu 默认锁定了 root 密码 （/etc/shadow 里 root 的密码字段是 !），也就是说正常情况下根本无法用 su 切到 root。这不是 bug，而是设计------强制用户走 sudo 这条路，让每一次提权都被记录下来。

4. su 到其他普通用户

su 也可以切到别的普通用户，同样需要对方密码：

复制代码

su - zhangsan

这种方式在运维里很常见：用 root 登录后 su - app 切到应用账号去跑服务，避免服务以 root 身份运行。

三、sudo：以他人身份执行命令

sudo（superuser do）解决的核心问题是：不用知道 root 密码，也能执行需要 root 权限的命令。

1. 基本原理

sudo 的关键在于验证的是你自己的密码，而不是 root 的密码 。它凭什么相信你有资格提权？靠 /etc/sudoers 这份配置文件。

Ubuntu 的默认配置里有一行：

复制代码

%sudo   ALL=(ALL:ALL) ALL

含义是：sudo 组里的所有成员，可以在任何主机上、以任何用户和组的身份，执行任何命令。你在 id 里看到的 27(sudo)，就是这句话在起作用。

所以"能不能 sudo"不是由你决定的，而是由 /etc/sudoers 决定的。 把用户从 sudo 组里移除，他就立刻失去了提权能力：

复制代码

sudo deluser student sudo

反过来，把一个普通用户加进 sudo 组，他就获得了完整的管理员权限：

复制代码

sudo usermod -aG sudo zhangsan

2. sudo 执行单条命令

最常用的形式是"临时借一次权限"：

复制代码

sudo cat /etc/shadow          # 以 root 身份读取
sudo apt install nginx        # 以 root 身份装包
sudo systemctl restart ssh    # 以 root 身份重启服务

命令执行完，权限立刻收回------你依然是普通用户。这是最安全、最推荐的用法：只在需要的那一条命令上提权。

第一次 sudo 会让你输入自己的密码，之后一段时间内（默认 15 分钟）不再重复询问，这就是所谓的"密码缓存"。

3. sudo -i：交互式 root shell

有时候确实需要连续执行多条管理命令，每次都加 sudo 太啰嗦，这时用 sudo -i：

复制代码

sudo -i
Password:                     # 输入自己的密码
pwd
/root

sudo -i 会启动一个交互式的登录 shell ，相当于"用 sudo 的方式完成了一次 su -"------环境变量、家目录全部按 root 来。

它和 su - 的对比是本篇的重点之一：

对比项	`su -`	`sudo -i`
需要谁的密码	root 的密码	自己的密码
需要什么资格	知道 root 密码即可	在 `/etc/sudoers` 中被授权
环境变量	完全切换为 root 的	完全切换为 root 的
工作目录	`/root`	`/root`
操作是否被记录	不记录	记录在 `/var/log/auth.log`
Ubuntu 默认可用性	不可用（root 密码锁定）	可用（sudo 组成员）

为什么 sudo -i 更优？ 因为它把"谁在什么时候提权、执行了什么"全部写进了日志。在多人共管的服务器上，这是一条不可替代的审计线索------su - 之后做什么，日志里是看不到的。

4. sudo -s 与 sudo su -

顺带认识两个变体：

复制代码

sudo -s          # 启动 root shell，但保留当前用户的环境变量（不完全切换）
sudo su -        # 用 sudo 拿到 root 权限后，再执行 su -，效果接近 sudo -i
sudo -u zhangsan whoami   # 以指定用户身份执行，不限于 root

sudo -s 和 su 一样存在环境不完整的问题，日常更推荐 sudo -i。

5. 提权的边界

必须强调一点：sudo 的危险性和 root 完全一样。 sudo rm -rf / 和 su - 之后 rm -rf / 造成的后果没有任何区别。区别只在于"是否需要输密码"和"是否留下日志"。

所以正确的心态是：把 sudo 当成一把需要谨慎使用的钥匙，而不是一个省事的开关。

四、文件的三种拥有关系

一个文件在 Linux 里从属于三个角色，这就是"三种拥有关系"：

角色	英文	说明
拥有者	owner / user	创建文件的用户，通常是文件的"主人"
所属组	group	文件归属的用户组，组内成员共享一组权限
其他用户	others	既不是拥有者、也不在所属组里的所有其他用户

用 ls -l 一眼看出这三者：

复制代码

ls -l hello.c
-rw-r--r-- 1 student student 125 Oct 20 10:00 hello.c

逐段拆解这行输出：

复制代码

-rw-r--r--   1   student   student   125   Oct 20 10:00   hello.c
└────┬───┘   │   └──┬──┘   └──┬──┘   └┬┘   └─────┬────┘   └──┬──┘
  权限位     硬链接数 拥有者    所属组    大小     修改时间      文件名

student student 这两段就是拥有者和所属组。绝大多数情况下它们相同（因为用户创建文件时，所属组默认是用户的主组），但它们完全可以不同 ------这正是 chown、chgrp 存在的意义。

为什么需要"组"这一层

设想一个项目组：张三、李四、王五三个人要共同维护一批代码文件，但不能让其他部门的人看到。如果没有"组"这个概念，你只能做到"只让自己看"或"让所有人看"，没有中间地带。

有了组，就可以做到：拥有者完全控制，组内成员读写，其他人一无所知。 这是 Linux 权限模型用三个角色而非两个角色的根本原因------它在"私有"和"公开"之间提供了一层"团队共享"。

五、文件的属性与九位权限

1. 权限位的构成

ls -l 输出开头的十个字符，是理解权限的全部入口：

复制代码

-rwxr-xr--
│└┬┘└┬┘└┬┘
│ │  │  └── 其他用户（others）的权限
│ │  └───── 所属组（group）的权限
│ └──────── 拥有者（owner）的权限
└────────── 文件类型

第 1 位是类型（- 普通文件、d 目录、l 软链接），后 9 位每 3 个一组，分别对应拥有者、组、其他人。

每一组里三位固定顺序是 rwx：

字母	含义	对文件	对目录
`r`	read 读	可以读取文件内容（`cat`、`less`）	可以列出目录内容（`ls`）
`w`	write 写	可以修改文件内容	可以在目录内创建、删除、重命名文件
`x`	execute 执行	可以作为程序执行	可以进入该目录（`cd`）
`-`	无此权限	---	---

所以 -rwxr-xr-- 翻译过来就是：普通文件，拥有者可读可写可执行，组内成员可读可执行不可写，其他人只能读。

2. 目录权限的特殊性（重点）

目录的 r、w、x 含义和文件差别很大，这是新手最容易糊涂的地方：

目录的 r ：能不能"看到"目录里有哪些文件名。只有 r 没有 x 时，ls 能看到名字列表，但读不到每个文件的详细信息（ls -l 会报错）。
目录的 x ：能不能"穿过"这个目录。进入目录（cd）、访问目录内的文件、查看文件属性，都依赖 x 。只有 r 没有 x 的目录，你能看到文件名，却打不开任何一个。
目录的 w ：能不能在目录里增删文件 。注意这里的语义------删除一个文件，看的是目录的 w 权限，而不是文件本身的 w 权限。

最后这条极其重要，它解释了一个常见困惑：为什么 rm 删不掉一个只读文件？其实通常不是文件权限的问题，而是它所在的目录没有 w 权限 。反过来，即使文件本身是 444（只读），只要目录可写，你依然能删掉它------因为删除本质上是"从目录的目录项里抹掉这一条记录"。

3. 权限的数字表示

三位权限正好可以用三位二进制表示，转成十进制就是一个 0--7 的数字：

权限	二进制	数字
`---`	000	0
`--x`	001	1
`-w-`	010	2
`-wx`	011	3
`r--`	100	4
`r-x`	101	5
`rw-`	110	6
`rwx`	111	7

记忆口诀：r = 4，w = 2，x = 1，相加即得。 于是 rwxr-xr-- = 754，rw-r--r-- = 644，rwxrwxrwx = 777。

六、chmod：修改权限

chmod（change mode）用于修改文件或目录的权限，有两种写法。

1. 数字法

复制代码

chmod 755 script.sh       # rwxr-xr-x
chmod 644 config.ini      # rw-r--r--
chmod 700 private/        # rwx------
chmod 600 id_rsa          # rw------- 私钥标准权限

三个数字依次对应拥有者、组、其他人，一次设完九位。这是最常用、最简洁的方式，也最好记。

2. 符号法

数字法是"整体覆盖"，符号法可以"增量修改"：

复制代码

chmod u+x script.sh       # 给拥有者加执行权限
chmod g-w file.txt        # 去掉组用户的写权限
chmod o=r file.txt        # 把其他人权限设为只读（覆盖）
chmod a+r file.txt        # 所有人加读权限
chmod u+x,g+x file.txt    # 多项用逗号分隔

符号含义：u 拥有者、g 组、o 其他人、a 所有人；+ 增加、- 移除、= 直接设定。

3. 递归修改

复制代码

chmod -R 755 project/     # 递归修改目录及内部所有内容

递归时要格外小心------它会把目录内的所有文件也一并改成 755，包括那些本该是 644 的普通文件。给文件加上不该有的执行权限，是很常见的疏忽。

4. 关于 chmod 777

复制代码

chmod 777 /var/www/html

这条命令的含义是：拥有者、组、其他所有人，都拥有读、写、执行权限。 也就是把这个目录对全世界完全敞开。

新手遇到"权限不足"的报错时，最常见的做法就是 chmod 777 了事。这确实能立刻消除报错，但它带来的是实实在在的安全风险：

任何人都能修改你的文件------包括植入恶意脚本；
任何人都能删除文件（因为目录可写），包括整个网站程序；
如果是 Web 目录，攻击者上传一个 PHP 文件就能直接执行任意代码；
它掩盖了真正的问题 ：报错的真实原因可能是目录属主不对、可能是进程运行用户不对，chmod 777 只是把这些原因统统绕过去了。

更合理的做法是先定位问题，再精确授权：

复制代码

# 反例：图省事
chmod 777 /var/www/html

# 正例：把属主改成 Web 服务的运行用户，其他人只读
sudo chown -R www-data:www-data /var/www/html
sudo chmod -R 755 /var/www/html
sudo chmod 644 /var/www/html/*.php

记住一条原则：777 是排查问题时的最后手段，不应该是第一反应。 在能被外网访问的机器上，chmod 777 几乎等同于"请来攻击我"。

七、chown 与 chgrp：修改归属

chmod 改的是"权限位"，chown 和 chgrp 改的是"归属关系"------两件完全不同的事。

1. chown：修改拥有者

复制代码

sudo chown zhangsan file.txt        # 把拥有者改成 zhangsan
sudo chown zhangsan:develop file.txt  # 同时改拥有者和所属组
sudo chown :develop file.txt        # 只改所属组（冒号前留空）
sudo chown -R zhangsan:develop project/  # 递归修改

: 这个分隔符是关键------冒号前是拥有者，冒号后是所属组 ，留空表示"这一项不改"。所以 chown :develop 和 chgrp develop 效果相同。

2. chgrp：修改所属组

复制代码

sudo chgrp develop file.txt         # 把所属组改成 develop
sudo chgrp -R develop project/      # 递归修改
chgrp student file.txt              # 普通用户也能把组改到自己所属的组

chgrp 只负责修改组，语义比 chown user:group 更清晰。日常简单场景下用它更直观。

查看系统里有哪些组：

复制代码

cat /etc/group
groups zhangsan        # 查看某个用户属于哪些组

3. 一个常见误解：chown 后权限可能"消失"

看这个场景：

复制代码

ls -l report.txt
-rw------- 1 student student 1024 Oct 20 10:00 report.txt

sudo chown zhangsan report.txt
ls -l report.txt
-rw------- 1 zhangsan student 1024 Oct 20 10:00 report.txt

属主换成了 zhangsan，但权限位 rw------- 没变。这意味着：zhangsan 现在能读写（因为它是拥有者，对应第一组 rw-），而原来的 student------尽管它是这个文件的创建者、也在所属组里------只能按"所属组"的身份去看，对应第二组 ---，连读都不行了。

这就是"改属主"的威力：权限位不变，但谁享受哪一组权限全变了。

八、角色如何匹配权限（最容易出错的地方）

1. 匹配规则：从左到右，只匹配一次

内核在检查权限时，判断顺序是固定的：

复制代码

1. 当前进程的有效用户 == 文件拥有者？   → 是，用第一组权限，判定结束
2. 否则，当前进程的组 ∈ 文件所属组？    → 是，用第二组权限，判定结束
3. 否则                                  → 用第三组权限

关键点在于"判定结束"四个字------匹配到哪一组，就只用那一组，绝不会往后累加。

2. 一个反直觉的例子

复制代码

ls -l data.txt
----rw-r-- 1 student develop 1024 Oct 20 10:00 data.txt

这个文件的拥有者是 student，拥有者权限是 ---（什么都不能做）；所属组是 develop，组权限是 rw-。假设 student 同时也是 develop 组的成员，那他能写这个文件吗？

很多人第一反应是"能，因为他在组里，组有 w"。错了。

因为内核第一步就匹配成功了：student 是拥有者，于是直接采用拥有者权限 ---，判定结束，根本不会去看组权限。结果是他连读都做不到，尽管组有读权限。

这就是"只匹配一次、不累加"的威力------它常常违反直觉，也是权限排查中最容易卡住的地方。如果一个用户明明在组里、组权限也有 w，却依然写不了文件，第一件事就应该检查他是不是文件的拥有者。

3. 排查权限问题的正确顺序

遇到 Permission denied，建议按这个顺序检查：

复制代码

id                          # 我是谁，在哪些组里
ls -l file                  # 文件属主、属组、九位权限
ls -ld /path/to/dir         # 沿途每一级目录是否有 x 权限
namei -l /path/to/file      # 一次性查看路径上所有层级的权限

其中 namei -l 特别有用------它能一次列出路径上每一级目录的权限，因为"访问不了文件"的原因经常是某一级父目录缺少 x 权限，而不是文件本身的问题。

九、文件可执行的条件

1. 对普通文件

一个文件要能被当作程序执行，必须同时满足：

有 x 权限 ：拥有者/组/其他人中，至少有一个角色对应位置是 x（取决于你是谁）；
内容是合法的可执行格式 ：ELF 可执行文件、Shell 脚本（有正确的 shebang）、Python 脚本等。一个纯文本文件即使有 x，执行时也会报 Exec format error。

chmod +x hello.sh
./hello.sh

Shell 脚本要能直接执行，第一行必须是 shebang：

bash 复制代码

#!/bin/bash
echo "hello"

如果没有 shebang 而有 x 权限，Shell 会尝试用当前 shell 去解释它------有时能跑，有时行为不可预期。

2. 对目录

目录的 x 权限含义是"能否进入/穿越"。访问目录内的文件，要求沿途每一级目录都有 x 权限。

复制代码

chmod 644 /home/student/project      # 目录丢了 x 权限
cat /home/student/project/a.txt
cat: /home/student/project/a.txt: Permission denied

即使 a.txt 本身是 777，照样读不了------因为无法"穿过" 目录。这个现象很能说明问题：权限检查是逐层进行的，任何一层的缺失都会阻断访问。

十、属主与属组：拥有者也无权修改

这是本篇最需要强调的一条，也是很多人第一次遇到时的困惑来源。

1. 拥有者不能改拥有者

普通用户即使拥有某个文件，也无法用 chown 把它的拥有者改给别人：

复制代码

ls -l myfile.txt
-rw-r--r-- 1 student student 0 Oct 20 10:00 myfile.txt

chown zhangsan myfile.txt
chown: changing ownership of 'myfile.txt': Operation not permitted

哪怕这个文件是你亲手创建的，哪怕你有它的全部权限，chown 依然会被拒绝。

为什么这么设计？ 有三个实际原因：

防止甩锅：如果可以随意改属主，一个用户就能把违规文件"送"给别人，追溯责任时无据可查；
磁盘配额：Linux 的磁盘配额按用户计算。如果用户能把文件转给别人，就能绕过自己的配额限制；
安全边界：文件的属主决定了谁能设置 SUID 之类的高危权限，随意改动会破坏整个安全模型的根基。

2. 拥有者能不能改属组？

这里要区分清楚，改组和改属主的规则并不完全相同：

复制代码

# 属于自己所在的组 ------ 允许
chgrp develop myfile.txt
ls -l myfile.txt
-rw-r--r-- 1 student develop 0 Oct 20 10:00 myfile.txt

# 改成自己不在的组 ------ 拒绝
chgrp root myfile.txt
chgrp: changing group of 'myfile.txt': Operation not permitted

规则是：拥有者可以把文件的组改成自己所属的某个组，但不能改成自己不属于的组。 因为把自己不在的组加给文件，等于给一个自己无法控制的群体授了权。

3. 只有超级用户或提权后才能改

改拥有者、改到自己不属的组，必须由 root 执行，或者通过 sudo 临时提权：

复制代码

sudo chown zhangsan:develop myfile.txt    # 正确
sudo chgrp root myfile.txt                # 正确

这里正好把本篇的两条线索接上了：su - 和 sudo -i 让你成为 root，成为 root 之后 chown 才不再被拒绝。"只有超级用户或提权才可以改归属"和"sudo 是日常提权的正确姿势"，是同一个问题的两面。

4. 归纳

操作	拥有者	组成员	其他	root / sudo
`chmod` 改权限	可以	不可以	不可以	可以
`chgrp` 改到自己所属的组	可以	不可以	不可以	可以
`chgrp` 改到自己不属的组	不可以	不可以	不可以	可以
`chown` 改拥有者	不可以	不可以	不可以	可以

这张表可以概括为一句话：权限位归拥有者管，归属关系归 root 管。 这是 Linux 权限模型里一条清晰的分界线。

十一、综合小实战

把本篇的知识串起来，模拟一个真实场景：部署一个静态网站，让 Web 服务能读、让团队能改、让外人只能看。

第一步，创建目录和文件，看清楚初始状态：

复制代码

mkdir -p /var/www/mysite
echo "hello" > /var/www/mysite/index.html
ls -l /var/www/mysite
-rw-r--r-- 1 student student 6 Oct 20 10:00 index.html

第二步，把属主和属组交给 Web 服务的运行用户与开发组：

复制代码

sudo chown -R www-data:develop /var/www/mysite
ls -l /var/www/mysite
-rw-r--r-- 1 www-data develop 6 Oct 20 10:00 index.html

第三步，目录设成组内可写、其他人可读，文件设成组内可写：

复制代码

sudo chmod 775 /var/www/mysite
sudo chmod 664 /var/www/mysite/index.html

第四步，验证一下自己（student，在 develop 组里）有什么权限：

复制代码

id
groups=1000(student),27(sudo),1001(develop)
ls -l /var/www/mysite/index.html
-rw-rw-r-- 1 www-data develop 6 Oct 20 10:00 index.html

student 不是拥有者，但在 develop 组里，于是匹配到第二组 rw-------可读可写，但不能执行。这正是我们想要的效果。

第五步，检查一下路径上每一级目录有没有 x：

复制代码

namei -l /var/www/mysite/index.html

如果某一级缺 x，浏览器访问就会 403，而文件权限看起来却完全正常------这就是为什么必须逐层检查。

最后，如果想收回某个人的权限，把他从组里移除即可，不需要动文件权限：

复制代码

sudo deluser zhangsan develop

这正是"组"这一层设计的价值：权限授予一次性配置好，人员的进出通过组成员来管理。

总结

本篇可以归为四组记忆。

身份切换： su 切身份不切环境，su - 完整登录式切换；su 需要 root 密码，而 Ubuntu 默认锁定了 root 密码，所以日常走 sudo。sudo 验证的是自己的密码，凭借的是 /etc/sudoers 里的授权；sudo -i 相当于"用 sudo 完成一次 su -"，环境完整且全程留痕，是连续管理操作的首选。

三种拥有关系与九位权限： 拥有者、所属组、其他人各占三位，r=4、w=2、x=1。文件的 w 是改内容、目录的 w 是增删文件（删除看目录权限，不看文件权限 ）、目录的 x 是能否穿越，访问文件要求沿途每级目录都有 x。

三把工具： chmod 改权限位（数字法 755 最简洁，符号法 u+x 适合增量调整），chown 改属主（user:group 可一起改），chgrp 改属组。chmod 777 是掩盖问题而非解决问题，应当先定位原因再精确授权。

两条硬规则： 一是权限匹配从左到右、只匹配一次、绝不累加 ------拥有者即使同时在属组里，也只享受拥有者那三位，这解释了绝大多数"明明在组里却还是不行"的怪现象；二是权限位归拥有者管、归属关系归 root 管 ------拥有者可以 chmod、可以把组改成自己所属的组，但改拥有者、改成自己不属的组都必须 sudo。这不是限制，而是整个安全模型的基石。

把这些放在一起看，Linux 的权限系统其实并不复杂：三个角色、三种权限、一次匹配。复杂的是那些反直觉的边界条件，而它们的每一条背后，都有明确的安全考量。

后续我们将继续深入 Linux 的相关知识，敬请期待。

本文是《Linux系统篇》系列的第四篇，如需命令速查表或练习环境，可在评论区留言。