文件共享与保护：inode、硬链接、软链接与Linux权限机制详解

最近在整理操作系统笔记，我发现“文件共享和保护”这一章在课本里篇幅不算长，却是最容易在实际项目里翻车的内容。明明就是一个普通的文本文件，为什么别人能看见却改不了？为什么我删掉软链接，原文件居然还在？为什么把一个目录共享出去之后，别人就能把整个项目目录“顺走”？这些问题的答案，几乎都藏在文件系统如何实现“共享”和“保护”这两件事里。

作为我这套 OS 学习笔记的第 34 篇，这篇我打算换个方式写，不完全按课本顺序罗列知识点，而是从“一个问题是怎么引出来的”出发，顺着原理讲到命令，再从命令回到原理。这篇文章的目标读者很明确：正在学操作系统、被绕昏头的学生，以及平时要跟 Linux 服务器打交道、经常被权限搞得头大的开发同学。你可以把它当一篇独立的原理梳理，也可以当作遇到实际问题时的排查手册来用。

1. 先看本质：共享不过是指向同一个 inode 的多个入口

1.1 为什么需要共享：没有“引用”就只能复制

在单用户操作系统时代，文件共享这个概念基本不存在。整个机器只有你一个人，所有文件天然都是“我的”，不存在让别人看、让别人改的问题。多用户系统出现以后，事情立刻不一样了：用户 A 写完一份需求文档，用户 B 今天也要改，如果让 B 复制一份过去，后面就会冒出两个版本，你说不清楚哪个才是权威版本。更要命的是，系统里的可执行程序、公共库文件，如果每个用户都复制一份，磁盘很快就会塞满。

教材在讲这一节时通常会把共享的需求提炼成三类：第一，多个用户协同完成同一个任务，需要读写同一份文件；第二，系统级的公共资源希望能全局可见，但同时只保存一份；第三，用户希望在自己的不同目录下快速访问同一个文档，不用重复拷贝。这三句话翻译成一句大白话就是：让多个不同路径都能访问到同一个文件实体，而不是维护多个副本。

这里有个很容易被忽略的细节：共享省的不只是磁盘空间，还有“一致性维护成本”。如果同一个数据只存在一份，那么任何人改完，其他人立刻就能看到最新结果，不存在同步问题。副本一多，你就要引入版本管理、同步机制，这些都会显著增加复杂度。所以文件共享本质上是操作系统提供的一种“引用”能力，让同一份数据可以被多个入口引用。

1.2 目录项和文件实体是两码事

要彻底理解文件共享，必须先打破一个直觉：我们平时说的“文件”，其实包含两个完全不同的东西——目录项（dentry）和文件实体（inode + 数据块）。

磁盘上真正存储数据的是 inode 和数据块。inode 里记录了文件的元数据，比如大小、属主、权限、时间戳，以及指向数据块的指针。而目录项是什么？它是我们在路径中看到的那个“名字”。目录项的核心作用是把文件名映射到对应的 inode 号。也就是说，当我们访问/home/a/report.md时，内核要做的事情是：沿着目录层级找到report.md这个目录项，读出它指向的 inode 号，再通过 inode 找到真正的数据块。

这个设计一旦讲清楚，文件共享的定义就非常清爽了：让两个或两个以上的目录项指向同一个 inode。比如/home/a/report.md和/share/report.md这两个路径，表面上看起来是两个位置，但如果它们内部记录的 inode 号相同，它们就是同一个文件的多个入口。这时候你通过其中一个路径修改文件，另一个路径看到的内容也会跟着变，因为它们本来就是同一份数据。

1.3 共享省了空间，却让“所有权”变得模糊

一提到“共享”的好处，很多人第一反应是省空间，这当然没错。可共享带来的麻烦也同样明显：当一份文件可以被多个路径访问时，就说不清楚谁是它的“主人”了。谁有权修改？谁有权删除？删除之后别人要不要知道？这些问题不解决，共享就是灾难。

所以操作系统不会直接说“谁都能访问”，而是设计了两套配套机制：一套是共享实现机制，解决“怎么让多个入口指向同一份文件”，也就是硬链接和软链接；另一套是保护机制，解决“共享归共享，每个用户到底能对这个文件做什么”，也就是权限控制、加密等手段。理解了“共享会模糊所有权”这个前提，后面很多看似奇怪的限制（比如目录不能硬链接、权限位里有 rwx 三分组）就都有了合理动机。

2. 硬链接与软链接：两条路径，两种性格

2.1 硬链接：在同一个文件系统里再造一个目录项

如果需要“在另一个位置访问到已有 inode”，最直接的办法就是创建硬链接。系统会新建一个目录项，把它指向某个已经存在的 inode，同时把这个 inode 的链接计数加 1。数据块一个字节都不会复制，只是多了一个“门牌”。在 Linux 里，ln target link_name就是在创建硬链接。

但硬链接有几个非常硬性的限制，必须理解清楚。

第一，不能跨文件系统。这是因为 inode 号只在它所在的分区范围内有效。两个不同的磁盘分区，各自都有编号为 100 的 inode，这完全正常。如果允许硬链接跨分区，你就没法通过 inode 号唯一定位文件，所以硬链接只允许发生在同一个文件系统内部。

第二，不能对目录创建硬链接。我到现在还经常看到有人问“我想把整个目录链过去，为什么 ln 不让我链”。答案下一节详细说，这里先记住结论：对目录做硬链接会导致目录树出现环，破坏树形结构，所以系统直接禁止。

第三，硬链接没有“主次之分”。有人会觉得硬链接是“复制出来的副本”，这是很大的误解。实际上，原文件名和硬链接名是平级的，它们指向同一个 inode，没有任何一个比另一个更“原始”。你删除最初创建的那个路径，只要还有别的路径引用这个 inode，数据就依然存在。

2.2 软链接：存路径字符串，天生就会“断”

软链接（也叫符号链接）的思路和硬链接完全不同。它不是给现有 inode 加目录项，而是创建一个新的、独立的文件实体。这个特殊的文件里保存的是另一个文件的路径字符串。当你访问软链接时，内核会读出这个路径串，再去解析它指向的目标。

用ln -s target link_name就可以创建软链接。

软链接有它自己的特点。

第一，不存在引用计数问题。它不会让目标文件的链接计数加 1，因为从 inode 层面看，目标文件根本没多出一个入口。

第二，可以跨文件系统，也可以指向目录。因为软链接里存的是路径，路径跟文件系统编号没关系，跨分区、跨设备都能用。

第三，天然会“断链”。如果目标文件被删除，软链接并不会跟着消失，它依然存在于目录里，只是当你访问它时，内核发现它指过去的路径已经不存在了，于是报No such file or directory。很多新手第一次遇到这种情况，会误以为自己把文件搞坏了，其实只是链接失效了。

这里我补充一个实用的认知：软链接本身是一个文件，它有自己的 inode、自己的大小（大小等于路径字符串的长度）。你用ls -l查看软链接，会看到形如lrwxrwxrwx 1 user group 5 ... soft.txt -> a.txt，那 5 就是路径字符串a.txt的字节数。搞清楚这一点，再看文件和链接之间的区别，就不会再晕了。

2.3 两种链接的选型标准：我平时是怎么决定的

硬链接和软链接不是谁替代谁的关系，它们在设计目标和适用场景上完全不同。我做一个对比表，方便你对照着选：

我自己的选择标准很朴素：同分区内、希望多个路径平等访问同一份数据，优先用硬链接。比如我在服务器上维护配置模板，希望在/etc/project和/data/template两个位置都能访问同一份配置，用硬链接最合理。要链接目录、要跨分区、要给程序提供一个“快捷方式”、或者希望一眼能看出这是一个链接，用软链接。

还有一个小坑值得提醒：如果需要在项目里同时打包软链接和它指向的目标文件，要注意软链接的相对路径是否还能解析。很多时候移动整个目录之后，软链接会变成“指向不存在的目标”的坏链，这就是所谓“移动后失效”。硬链接没有这个问题，只要还在同一个文件系统内，inode 不会被移走。

3. 共享引发的三大经典麻烦：删除、循环、一致性

3.1 删除语义与引用计数：为什么删了“原文件”数据还在

共享之后，第一个麻烦出现在删除操作上。我们平时说“删除文件”，在操作系统的实现层面其实是unlink，也就是“解开这个目录项与 inode 的绑定关系”。对于普通文件，目录项原本是唯一入口，解绑之后 inode 的链接计数变成 0，系统就会回收这个 inode 和它占用的数据块。但如果有两个目录项同时指向同一个 inode，链接计数是 2，删除其中一个路径只是把计数从 2 变成 1，数据块还在，另一个路径依然能正常访问。

这其实是一个非常精妙的设计：系统不需要人为判断“谁是文件主人”，只要保证 inode 的引用计数大于 0，数据就永远保留。所以“删除原文件”这个说法只对链接数为 1 的普通文件有意义。在共享场景里，你删除的只是“一个入口”，而不是“文件本身”。

我在实际维护服务器时遇到过这种情况：一个运行中的程序 Write 一个日志文件，管理员嫌日志目录太乱，清理时把主路径删了，但另一个硬链接还指向同一个 inode，于是日志文件一直在被写，磁盘空间也被占用，df 却显示已删。最后排查半天，发现是链路计数不为 0 导致 inode 没有释放。遇到“文件删了但空间没释放”的情况，检查硬链接数应该是第一反应。

3.2 目录循环：为什么系统不允许对目录做硬链接

硬链接不能用于目录，这个限制经常被当成“规则”背，但很少有人仔细想过为什么。我可以把问题描述得很具体：假设我们允许对目录创建硬链接，然后执行ln /data /data/self，让/data目录里出现一个指向自身的入口。此时如果你递归遍历/data，会进入/data/self，然后再进入/data/self/self，一路无限嵌套下去，永远没有尽头。对目录做删除、统计、复制这类递归操作时，也同样会陷入死循环。

正因为如此，经典操作系统在文件系统层面直接禁止对目录建硬链接，用硬性规则保证目录树始终是一棵树而不是一张可能带环的图。那么想共享目录怎么办？用软链接。软链接不会增加目标目录的 inode 引用计数，它只是一个“路径快捷方式”。即使软链接指向一个目录，访问时也只是从这个路径字符串继续往下走，目录树本身不产生环。

另外还有一个容易出问题的地方：符号链接如果指回自己的祖先目录，在递归遍历时若不加以限制，同样会陷入无限循环。很多查找工具在处理符号链接时默认不跟随，或者设置深度上限，就是因为这个原因。

3.3 多人同时修改：文件系统自己解决不了的一致性

共享还带出一个非常现实的业务问题：两个用户同时打开同一个文件，各自修改并保存，最后会发生什么？

从文件系统层面看，写入操作会被拆成多个磁盘操作，最终结果很可能是“后写覆盖先写”。A 写了版本 1，B 紧接着写版本 2，文件里最后留下的可能是版本 2，也可能因为未做同步出现半旧半新的混合内容。这叫做“丢失更新”，是共享场景中最典型的数据一致性问题。

关键认知是：文件系统不负责解决这种业务级别的一致性。操作系统能保证的是单个写入操作要么成功要么失败，以及崩溃后不会出现元数据错乱，但它不知道你写的文档、代码、数据表应该以什么规则合并。于是实际项目里会用更上层的机制来处理：进程间用文件锁（flock、fcntl）防止并发写入，团队协作干脆引入版本控制系统，把“共享文件”的问题从文件系统上彻底挪走。

有同学会觉得这有点“推卸责任”，但换一个角度想，文件系统如果把业务合并规则硬编码进去，那才真是灾难。它只应该提供基础同步原语，把“谁先改谁后改、冲突怎么合并”的决定权留给应用去完成。

4. 保护机制第一层：从访问控制矩阵到 ACL

4.1 保护到底在保护什么

共享关心的“能不能访问到”，保护关心的则是“访问到什么程度”。文件保护要面对的安全威胁主要是三类：未授权读取（泄露）、未授权修改（篡改）、未授权删除或破坏（破坏）。

一个完整的保护体系通常包含三件事：身份认证，确认“你是谁”；授权，确认“你能对文件做什么”；审计，记录谁在什么时候做了操作。操作系统里的文件权限系统主要负责第二件事，也就是授权。它做的事情是：在每次打开、读取、写入、执行文件时，根据文件记录的权限信息，判断当前用户是否具备相应权限。

这里我特别想说一个常见的误解：很多人把“保护”等同于“权限位”，这其实把问题看窄了。权限位是保护的一种实现方式，但不是全部。加密也是一种保护，而且它在某些场景下比权限位可靠得多。后面我会专门讲口令和保护的关系。

4.2 访问控制矩阵为什么没法直接落地

课本在讲访问控制时会先引入一个抽象概念：访问控制矩阵。这个矩阵的行是系统中的用户，列是每个文件，矩阵的每个格子里写着该用户对这个文件的权限，比如read、write、execute的集合。

逻辑上非常理想，但一落到工程上就完了。假设系统有 1000 个用户、100 万 个文件，那就是 10 亿个格子，其中绝大多数都是空的。真要拿一个二维矩阵去存，内存和磁盘都扛不住。所以实际系统永远不会直接存这个矩阵，而是把它拆成两种更经济的形式。

一种叫访问控制表（ACL），按“文件”组织：每个文件带一个小列表，写明“谁能用什么权限访问我”。查询时只要看当前用户在这个文件的列表里是什么权限即可。另外一种叫用户能力表，按“用户”组织：每个用户带一个列表，写明“你能访问哪些文件、每种权限是什么”。优点是查某个用户所有权限很快，缺点是搞权限回收时你必须遍历所有文件，把相关条目删掉，极为痛苦。

4.3 Unix 的 rwx 就是 ACL 的极简版

Unix 的权限位可以看作 ACL 的一种高度压缩形式。它不是针对每个用户单独记录权限，而是把用户聚成三类：属主（owner）、属组（group）、其他用户（other）。每个类别再分别指定读（r）、写（w）、执行（x）三种权限，合起来就是九个 bit，再加上特殊权限位，存到 inode 里。

这里有一个长期困扰新手的问题：目录上的 rwx 和文件上的 rwx 含义完全不同。

• 文件上的读表示读取文件内容，写表示修改文件内容，执行表示把这个文件当作程序运行。
• 目录上的读表示可以列出目录里的文件名，写表示可以在目录中创建、删除、重命名文件，执行（常被称为“搜索权限”）表示可以“进入”这个目录并访问其中知道名字的文件。

有一种很容易让人懵的现象：你拥有某个目录的执行权限但没有读权限，那么你用ls这个目录会提示无权限列出内容，但如果你明确知道里面有个文件叫data.txt，你可以直接读取它。因为你“能进入目录、能精确定位文件名”，但“不能枚举目录内容”。这看起来有点别扭，但只要把“目录读=列出清单”和“目录执行=进入”分开理解，就不奇怪了。

再比如，用户对目录有写权限，但不是文件属主，用户能不能删除别人放在这个目录里的文件？在许多 Unix 系统里，默认是可以的，因为删除操作的本质是修改目录项，而不是修改文件本身，只要你对该目录有写权限，你就在做“改动目录内容”的操作。这也是为什么像/tmp这种共享目录要额外引入 sticky bit（粘贴位）来限制：有 sticky 位的目录里，只有文件属主、目录属主或特权用户才能删除或重命名文件，避免任何人乱删别人的临时文件。

5. 保护机制第二层：口令、加密与集中访问控制

5.1 口令保护：看着简单，用起来全是问题

口令保护应该是最古老、最容易理解的一种文件保护方式：我在访问文件之前必须先输入一个口令，口令对了才允许操作。它实现起来很简单，看起来也很直观，但在工程实践里处处是坑。

第一，口令保护通常只保护“访问入口”，不保护“存储内容”。口令验证通过之后，文件的读写命令照常走底层的磁盘接口，如果攻击者能直接把磁盘拆下来、用另一个操作系统读取数据块，那文件内容依然会暴露。第二，口令的传输也很容易出问题。口令在认证过程中如果走的是明文通道，抓包就能看到。第三，多人共享同一个口令时，无法区分具体是哪个用户，出了安全问题没法追责。最后，口令的回收也是一团乱麻：有人离职了，你还得改掉所有共享文件的口令，否则他就是永远的“隐形读者”。

所以口令保护在现代操作系统里基本不会作为主要的文件保护机制，顶多作为某些场景的辅助手段。真正负责保护的是权限系统，以及下面要说的加密。

5.2 加密保护：把最后一道防线放进文件本身

加密保护的核心思想是：即使数据被人拿到了，没有密钥也读不出内容。权限系统保护的是“访问路径”，而加密保护的是“数据本身”。两者是不同维度的防线。

在学习文件系统时，我们通常把加密分为两类来理解。一类是透明文件加密/文件级加密，文件系统在读写路径上自动完成加解密，应用程序无感，文件在磁盘上以密文形式存在，但合法用户在打开文件时看到的是明文。另一类是全盘加密，整个磁盘都被加密，系统启动时需要输入密钥才能解锁。

我的判断是：如果文件只存在本机，并且操作系统用户管理得还算严格，权限位通常已经够用；但一旦文件会进入备份介质、移动设备、云盘，或者会脱离当前操作系统的管辖，加密就不再是选项而是必须。很多人只把文件设为 600 权限，以为安全了，结果备份盘丢了之后直接泄露。本质问题是备份盘上的文件并不认识 Unix 的权限位，到了别的操作系统上，那些权限位就是一堆无意义的元数据，数据块本身是什么内容，就能被直接读出。

加密也有代价。最大的代价是性能：加解密会占用 CPU 和 IO，文件越大越明显。另一个代价是密钥管理：密钥丢了，谁都解不开，比误删还恐怖。所以在工程实践中，通常不是让每个文件都单独拥有一个密钥，而是采用“一条主密钥 + 多条文件密钥”的分层设计，主密钥保护文件密钥，文件密钥分别保护各自的数据。这样既避免了把所有文件绑在同一把钥匙上，又不至于让密钥数量失控。

5.3 分布式场景下的集中访问控制

单机场景下，ACL 和权限位已经能解决“谁可以访问”的问题。但一个人不可能只在一台机器上工作，分布式文件系统和网络存储场景下，“用户身份”必须跨越机器边界被识别。如果每台机器各自维护一套账号体系，那权限配置会变得极其混乱，同一个用户在这台机器上是 A，在另一台机器上又变成 B，文件到底该认谁？

所以现代的分布式文件系统普遍采用集中的方式管理访问控制：认证环节由独立的认证中心负责，用户先拿到一个可验证的凭证；文件服务器根据这个凭证确定用户身份，再查询该共享目录或文件配置的权限，决定是否允许读写。此时的“共享”粒度已经从单个文件上升到“共享某个存储区域”，在共享区域之内，再按用户和组进一步划分权限。

我对这类机制的学习体会是：集中控制的本质是“把用户的身份判断从每个文件上剥离出来，放到统一的地方处理”。单机版文件保护解决的是“文件自身”的管理，分布式场景下的保护解决的是“身份如何在多机间保持一致”的问题。两者互为补充，缺一不可。

6. 亲手验证：从命令行观察共享与保护的每个细节

6.1 inode、链接数、断链，一条命令全看见

理论说再多，不如自己跑一遍。我在学习时有一个很笨但很有效的办法：把笔记里说的硬链接、软链接、删除、断链全部在 shell 里做一遍，观察每个命令的输出变化。

先建一个工作目录，创建原始文件：

mkdir -p /tmp/share_demo && cd /tmp/share_demo echo "这是一份共享文档" > origin.txt

然后分别创建硬链接和软链接，用ls -li查看 inode 和链接数：

ln origin.txt hard.txt ln -s origin.txt soft.txt ls -li

输出会显示类似这样的信息：

total 16 123456 -rw-r--r-- 2 user group 30 Jul 1 10:00 hard.txt 123456 -rw-r--r-- 2 user group 30 Jul 1 10:00 origin.txt 123457 lrwxrwxrwx 1 user group 9 Jul 1 10:00 soft.txt -> origin.txt

看到hard.txt和origin.txt的 inode 号相同、链接数为 2，而soft.txt是完全不同的 inode、链接数为 1，并且明显标了->指向，哪怕不看任何文档，也能立刻理解硬链接和软链接的本质区别。

接下来通过任一入口修改文件，验证共享关系：

echo "第二次写入" >> hard.txt cat origin.txt

origin.txt里会出现新写入的内容，因为硬链接改变的是同一个 inode 对应的数据。如果通过soft.txt写入，效果也一样，因为内核解析到这个软链接后，落笔的仍然是origin.txt指向的 inode。

再模拟“删除原文件后的差异”：

rm origin.txt cat hard.txt # 仍能读到内容，链接数减为 1 cat soft.txt # 报错：No such file or directory，链接已经断了

这一套小实验跑完，硬链接和软链接在“删除场景”下的区别就一目了然了。

6.2 权限位组合：能读不能写、能进目录看不到文件

权限问题在实践中千奇百怪，我挑几个最典型的现象说。

现象一：某用户在共享目录里，能打开文件看到内容，但编辑器保存时提示“Permission denied”。用ls -l一看，文件属主是别人，权限是-rw-r--r--，也就是属主有写权限，组和其他用户只有读权限。这个用户虽在 dev 组里，但文件所有者不是他，文件所在的组也不是 dev 组，那他自然没有写权限。要修，要么把文件属主改给他，要么把文件组改成该用户所属组并给组加上写权限：

chgrp dev project.conf chmod 660 project.conf

改成660之后，属主和组都可以读写，组内成员就能正常编辑了。

现象二：用户能“走进”目录，但ls执行时提示权限不足。这通常是目录权限为--x，只有执行权限没有读权限。执行权限让他能通过路径逐级进入，但没有读权限就不能枚举目录项。如果需要“进入并列出”，目录必须同时有读和执行权限，通常写成r-x。

现象三：用户能删除目录里的文件，但他的权限明明是rw-。这里最容易被忽略：删除文件改的是目录项，不是文件本身。只要用户对目录有写权限，他就能修改目录中的条目，也就意味着可以删除或重命名该目录下的文件，跟他本人对这个文件的权限没有直接关系。因此，共享目录如果要限制成员只能“往里放文件，但不能乱删别人的文件”，就必须给目录加 sticky bit，比如/tmp目录的权限就是drwxrwxrwt，最后的t表示粘贴位。有粘贴位的目录里，删除操作只对文件属主、目录属主或特权用户开放。

6.3 实操后给我的三点提醒

第一，不要随手chmod 777。“反正大家都要用，干脆全开”，这句话是权限事故的根源。共享应遵循“最小够用”原则：要读就给读，要写就给写，执行权限只在需要时给。一个目录开了 777，意味着所有用户都能在里面创建、删除、重命名任何人的文件，出问题根本无法追责。

第二，写权限和目录写权限都要复盘。你写的代码没问题，不代表配置没问题。排查权限类事故时，我会按顺序确认三件事：文件属主是谁、文件权限是什么、父目录权限是什么。前两个决定你能不能读写文件内容，第三个决定你能不能增删目录项。很多人只查了文件本身，漏掉了父目录的权限，最后绕了半天才发现根源在目录上。

第三，加密不能靠权限位替代。如果文件最终要备份、传输、交给合作伙伴，权限位保护已经失效，请戴口罩。更准确地说，请先加密再传输。我在实际项目中的习惯是，凡是涉及敏感信息的分发文件，一律在系统层面设置加密，文件本身的 Linux 权限只是第二道保险。

这套学习笔记写到这里，其实“共享”和“保护”这两件事是唇齿相依的：共享扩大了访问范围，保护则在范围扩大的同时划出了边界，没有保护的共享等于裸奔，没有共享的保护则会让协作寸步难行。最后再分享一个我个人养成的习惯：配置共享目录之前，先在一张纸上写下“哪类用户对哪个目录能做什么”，然后再把这条规则翻译成权限位的组合。这个简单的动作，帮我避开了很多只有等到出事才会暴露的坑。