【Linux 系统篇(五)】权限详解(二)

大家好，欢迎来到 huangjin007_ 的博客
⭐
个人主页：huangjin007_
🔥
文章收录专栏：Linux 内功修炼手册(系统篇)

总会有一些坚持能从冰封的土地里培育出十万朵怒放的蔷薇

Linux 系统篇(五) —— 权限详解(二)

文章目录

• Linux 系统篇(五) —— 权限详解(二)
• • 一、Linux 默认权限与 Umask 掩码机制
  • • 1.1 默认权限
    • 1.2 Umask 是什么？为什么我的文件权限不是 666 / 777？
    • 1.3 用二进制拆解 umask 运算
    • 1.4 普通用户的默认 umask 为什么是 0002？
    • 1.5 如何查看和修改 umask？
    • 1.6 Umask 存在的意义
  • 二、删除文件与文件本身权限无关
  • • 2.1 一次颠覆认知的实验
    • 2.2 多用户协作中的痛点
  • 三、粘滞位
  • • 3.1 粘滞位的作用
    • 3.2 如何设置粘滞位
    • 3.3 粘滞位验证
  • 结语：

一、Linux 默认权限与 Umask 掩码机制

1.1 默认权限

  当你在终端里敲下 touch test.txt 或者 mkdir mydir 时，内核并不是随机地给它们分配权限，而是有一套默认的“初始权限”作为起点。

• 普通文件：初始权限为 666，也就是 rw-rw-rw-。 你可能会奇怪，为什么不是 777 呢？原因很简单：出于安全考虑，系统不会默认给一个新建的普通文件加上“可执行（x）”权限。毕竟一个文本文件、图片或者代码源文件，大概率是不需要直接运行的。
• 目录文件：初始权限为 777，也就是 rwxrwxrwx。 目录和普通文件不同，它需要 x（执行）权限才能让用户 cd 进入。如果目录连 x 权限都没有，即使你有读取权限，也无法切换到该目录下工作。

小结：可以把初始权限理解为系统预设的一个“基础模板”，普通文件模板是 666，目录模板是 777。

1.2 Umask 是什么？为什么我的文件权限不是 666 / 777？

  但如果你马上用 ls -l 看一眼刚刚创建的文件，会发现它的权限根本不是 666 或 777，往往是 644 或 755。

  这是 umask 在起作用。

  umask（权限掩码）可以看作一个“过滤器”，它在文件或目录创建时，自动把你不希望出现的权限位屏蔽掉。计算最终权限的公式如下：

最终权限 = 初始权限 & (~umask) （即：初始权限 与 umask 取反之后的值，做按位与运算）

1.3 用二进制拆解 umask 运算

  我们先以超级用户默认的 umask 0022 和创建一个目录为例，把整个计算过程走一遍。

第一步：把八进制转换成二进制

• 初始目录权限 777 -> 二进制：111 111 111

• umask 值 022 -> 二进制：000 010 010

第二步：对 umask 取反 将 umask 的每一位取反（0变1，1变0）： ~022 = 111 101 101 转换成八进制就是 755。

第三步：按位与运算   将初始权限的二进制和取反后的 umask 二进制进行“与”操作（只有两个位都是 1 时，结果才为 1）。

111 111 111 (777，初始权限)
& 111 101 101 (~022，取反后的 umask)
—————-
111 101 101 -> 转回八进制就是 755

  所以最终目录权限为 755（即 rwxr-xr-x）。

  再来看普通文件，初始权限为 666，即 110 110 110，与同样的掩码（~022 = 111 101 101）进行按位与：

110 110 110 (666)
& 111 101 101 (~022)
—————-
110 100 100 -> 八进制 644

  最终文件权限就是 644（rw-r–r–）。

  这样一拆解，就很清晰了。umask 里值为 1 的位，在取反后变成 0，而与运算时“与 0”一定会让对应的权限位变成 0，也就是说 umask 中出现的权限位，最终会被屏蔽掉。超级用户的 umask 0022 中 group 和 other 的 w（写）位被置为 1，因此创建出来的文件属组和其他用户都没有写权限。

1.4 普通用户的默认 umask 为什么是 0002？

  大多数 Linux 发行版中，root 的默认 umask 是 0022，而普通用户的默认 umask 是 0002。区别就在于 owner（文件拥有者）的那个位上：普通用户 umask 的 owner 部分是 0，因此不会屏蔽自己的任何权限。但对 group 和 other 来说，依然屏蔽了写权限。

• root umask 0022 -> 文件 644，目录 755
• 普通用户 umask 0002 ->文件 664，目录 775

1.5 如何查看和修改 umask？

查看当前 umask：

  直接输入 umask 不带参数，会输出当前 shell 的掩码值，例如 0022 或 0002。

  如果想看到更人性化的符号形式，可以使用 -S 选项：

临时修改 umask：

umask 0002 # 设为 0002

  这样修改只对当前终端会话有效，关闭终端后就会恢复。

1.6 Umask 存在的意义

  你可能会想：既然系统可以直接规定创建出来的文件就是 644，为什么还要绕一个 umask 的圈子？

主要原因有两点：

二、删除文件与文件本身权限无关

2.1 一次颠覆认知的实验

  让我们先看一个场景：用户 zhangsan 在共享目录 /shared 下创建了一个文件，并把它设为只读（自己也只能看不能改）。然后用户 lisi 进入该目录，试图删除这个文件。

# zhangsan 的操作
$ mkdir /shared
$ chmod 777 /shared # 暂且设为全开放
$ cd /shared
$ touch zhangsan_file
$ chmod 444 zhangsan_file # 改为只读

# lisi 的操作
$ cd /shared
$ ls -l
total 0
-r–r–r– 1 zhangsan zhangsan 0 Sep 19 17:00 zhangsan_file
$ rm zhangsan_file
rm: remove write-protected regular empty file ‘zhangsan_file’? y
$ ls
（文件不见了！）

  是不是很吃惊？文件明明是只读的，而且还不属于 lisi，为什么他能删掉？

  核心结论：在 Linux 中，一个文件能否被删除，根本不取决于文件自身的权限，而是取决于其所在父目录的权限。

  具体来说，只要你对父目录拥有 写入（w） 和 执行（x） 权限，你就有权修改该目录下的目录项列表，包括删除里面的任何文件，无论这个文件是谁创建的、它的权限设置成什么样。

  删除操作修改的是目录的内容，而不是文件的内容。只要你对目录有写入权，自然就可以在其内执行增、删、改名字的操作。

  反过来，即便你对某个文件有 w 权限，但如果对父目录没有 w 权限，你也无法删除这个文件。你可以修改文件内容，但就是删不掉。

2.2 多用户协作中的痛点

  这个逻辑在单用户环境下可能没什么问题，但到了多用户协作场景，就会暴露出巨大的安全隐患。   假设我们有一个公共工作目录 /home/project，组内所有人都需要对它进行读写。为了让每个人都能创建文件，我们把它设成 777 。这时候，张三写了一个非常重要的代码文件，李四如果不小心或是恶意，完全可以直接 rm 掉，张三毫无办法。权限是开放了，数据安全却崩了。

  怎么解决呢？让操作系统知道：“这个目录是公用的，你可以进来创建自己的东西，但你不能乱动别人的文件。”

三、粘滞位

3.1 粘滞位的作用

  对于一个目录设置了粘滞位后，该目录下的文件，只有以下三类用户才能删除或重命名：

  换句话说，即使你对这个共享目录拥有写权限，只要文件不是你自己的，你就删不掉

3.2 如何设置粘滞位

  设置粘滞位使用 chmod +t 命令，后面跟目录名。

  注意权限字符串末尾多了一个 t，它位于原来 other 的 x 权限位置上：

• 如果 other 原来的 x 位是 x，加了粘滞位后显示为小写 t。
• 如果 other 原来的 x 位是 -（无执行权限），加了粘滞位后就会显示为大写 T，表示“粘滞位生效，但 other 没有执行权限，所以实际上无法使用该目录”。虽然可以设置，但这种组合几乎没有实用价值。

  用数字模式设置的话，粘滞位的数值是 1，要放在三位权限数字的前面，例如：

  这样目录权限就是 rwxrwxrwt。

3.3 粘滞位验证

  假设有一个共享目录，已经开启了粘滞位，用户 lisi 想删除不属于他的文件。

[root@localhost ~]# chmod 1777 /home/public
[root@localhost ~]# su – zhangsan
[zhangsan@localhost ~]$ cd /home/public
[zhangsan@localhost public]$ touch abc.c
[zhangsan@localhost public]$ exit

[root@localhost ~]# su – lisi
[lisi@localhost ~]$ cd /home/public
[lisi@localhost public]$ rm abc.c
rm：是否删除有写保护的普通空文件 "/home/public/abc.c"？y
rm: 无法删除"/home/public/abc.c": 不允许的操作

  系统先是按照删除普通文件那样问了一句“是否删除”，然而在 lisi 确认后，内核直接拒绝执行，并返回 Operation not permitted。这正是粘滞位在发挥保护作用。

  有几点需要注意：

• 粘滞位只对目录有效，对普通文件没有任何意义（如果你给一个普通文件设置了 +t，它只会显示为 t 或 T，但完全不影响删除行为）。
• 即使目录有粘滞位，root 依然可以为所欲为，因为它不受任何权限约束。
• 目录的所有者可以删除目录下任何人的文件。

结语：

  今天的内容到这里就结束了，希望你能有所收获~

干货整理到手抖，觉得有用的话，赏个三连回回血？__(:ᗤ」ㄥ)_ _