Re：Linux系统篇（八）权限篇 ·三：深度解析从 umask 位运算到粘滞位的“权力锁”

小此方2026-05-03 12:51


◆ 博主名称： 晓此方-CSDN博客 大家好，欢迎来到晓此方的博客。
⭐️Linux系列个人专栏： 【主题曲】Linux
⭐️ Re系列专栏：我们思考 (Rethink) · 我们重建 (Rebuild) · 我们记录 (Record)

文章目录

概要&序論

这里是正在准备完结C++的此方 上两篇我们分贝讲了权限对人，对文件的限制，今天我们接着上文继续讲解更加深入的内容，缺省权限、粘滞位等内容------力求全面且易于理解。好的，我们开始吧。

一，解析缺省权限与 umask 掩码

在 Linux 系统操作中，**我们经常发现新建的文件或目录自带一套初始权限。**这套权限并非随机分配，而是由系统通过特定的逻辑计算得出的。本文将深入探讨 Linux 缺省权限的生成机制。

1.1 回顾权限码

在 Linux 中，权限通常以八进制数字或二进制位表示。每组权限由三个位（r、w、x）组成：

  • r (Read) ：读权限，二进制 100，十进制 4。
  • w (Write) ：写权限，二进制 010，十进制 2。
  • x (Execute) ：执行权限，二进制 001，十进制 1。

对于任何文件或目录，权限被分为三组：拥有者（Owner） 、所属组（Group）以及其他用户（Others）。

1.2 权限掩码与 umask

umask （User file-creation mode mask）即"用户文件创建模式掩码"。它的存在是为了从起始权限中"过滤"掉不希望默认开启的权限位。

  • 查看掩码 ：在终端输入 umask。
  • 作用逻辑 ：umask 中被设为 1 的位，代表在创建文件时该权限将被屏蔽。

1.2.1怎么看你的机器的权限掩码

bash 复制代码 
[root@VM-0-9-opencloudos ~]# umask
0022

1.2.2怎么改你的机器的权限掩码

1.2.2.1临时生效的方法
bash 复制代码 
[root@VM-0-9-opencloudos ~]# umask 0002
[root@VM-0-9-opencloudos ~]# umask
0002
[root@VM-0-9-opencloudos ~]#

哎呀，我把之前的权限掩码忘掉了怎么办？退出重进一下就好了。 这种修改方式只是临时生效。

1.2.2.2永久生效的方法（不建议尝试）

方法 A：针对当前用户（推荐）

修改个人配置文件，仅影响当前用户的开发环境。

  1. 打开配置文件 ：使用命令 vim ~/.bashrc
  2. 在末尾添加 ：一行内容为 umask 0022
  3. 使配置生效 ：执行 source ~/.bashrc

方法 B：针对全系统所有用户（需 root 权限）

修改全局配置文件 /etc/profile 或 /etc/bashrc。 系统通常会根据用户的 UID 动态设置掩码：

  • UID > 199 的普通用户，默认掩码通常设为 0002。
  • root 用户 （UID 为 0），默认掩码通常设为 0022。

如下，修改掩码后的效果：

bash 复制代码 
[zbc@VM-0-9-opencloudos ~]$ touch test01
[zbc@VM-0-9-opencloudos ~]$ ls -l test01
-rw-r--r-- 1 zbc zbc 0 Apr 27 23:03 test01
[zbc@VM-0-9-opencloudos ~]$ umask 0777
[zbc@VM-0-9-opencloudos ~]$ touch test02
[zbc@VM-0-9-opencloudos ~]$ ls -l test02
---------- 1 zbc zbc 0 Apr 27 23:03 test02
[zbc@VM-0-9-opencloudos ~]$

1.2.3为什么要有权限掩码

umask 目的是什么？ 希望凡是在umask中出现的权限，都不应该在最终权限中出现

为什么要有umask？

  • ---> a. 默认权限，有OS自主决定，无法在创建前进行修改 --- 系统可配置，可以灵活满足需要的一种表现。
  • ---> b. 特殊情况下，配置umask，可以控制文件的默认权限，让我们的代码都是可控的。

1.3 文件与目录的初始权限与计算方式

1.3.1系统的起始权限

在不考虑掩码的情况下，系统对新建文件和目录有不同的预设起始值：

  • 普通文件 ：起始权限为 666 (rw-rw-rw-)。出于安全考虑，Linux 默认不允许新创建的普通文件具有执行权限（x）。
  • 目录文件 ：起始权限为 777 (rwxrwxrwx)。目录必须具备执行权限，用户才能进入（cd）该目录。

1.3.2.最终权限的计算公式

最终权限并不是简单的减法运算，而是在二进制层面的位运算。其严谨的逻辑公式如下：

最终权限 = 起始权限 & ( ∼ u m a s k ) 最终权限 = 起始权限 \ \& \ (\sim umask) 最终权限=起始权限 & (∼umask)

公式解析：

  1. ~umask（按位取反） ：将掩码位翻转。原本要屏蔽的位变为 0，原本要保留的位变为 1。
  2. &（按位与） ：将起始权限与取反后的掩码进行逻辑与运算。只有起始权限为 1 且掩码允许保留（即取反后为 1）的位，最终才会保持为 1。

1.3.3.案例实测（以 umask 002 为例）

假设当前 umask 为 0002，即二进制 000 000 010。

案例 A：创建目录（起始权限 777）

  • 起始权限 ：111 111 111 (777)

  • umask 取反 ：111 111 101

  • 逻辑与运算 ：

    text 复制代码 
      111 111 111  (777)
& 111 111 101  (~002)
-------------
  111 111 101  => 775

  • 最终权限 ：drwxrwxr-x (775)

案例 B：创建普通文件（起始权限 666）

  • 起始权限 ：110 110 110 (666)

  • umask 取反 ：111 111 101

  • 逻辑与运算 ：

    text 复制代码 
      110 110 110  (666)
& 111 111 101  (~002)
-------------
  110 110 100  => 664

  • 最终权限 ：-rw-rw-r-- (664)

二、 粘滞位

在多用户协作的 Linux 环境中，权限管理往往面临一个矛盾：既要允许用户在公共区域共同作业，又要防止用户的劳动成果被他人恶意破坏。粘滞位（Sticky Bit） 正是为了解决这一冲突而诞生的特殊权限位。

2.1 文件共享需求与协作背景

2.1.1协作环境的局限性

在 Linux 系统中，如果两个用户需要进行文件级别的协作，通常面临以下限制：

  • 私有目录无法协作 ：用户不能将协作文件放在任何一个人的私人账号（如 /home/XXX）下，因为其他协作成员往往没有进入该目录的权限。
  • 权限管理的"反直觉"特性 ：一个核心现象是------文件是否能被删除，与 文件本身的权限无关，而是由文件所属目录的 w（写）权限拥有者决定的。

第二点，这意味着 ，如果我们在一个权限开放的公共目录下协作，只要用户对该目录拥有 w 权限，他就可以删除该目录下的任何文件，即使该文件的拥有者并不是他，即使该目录是root的而你不是root 但是w又不能去掉，去掉之后共享就不复存在。

bash 复制代码 
#任何人在我的目录下创建的文件我都有权删除，因为这是我家。
[root@VM-0-9-opencloudos /]# su - zbc
Last login: Mon Apr 27 22:58:09 CST 2026 on pts/0
[zbc@VM-0-9-opencloudos ~]$ ls -al
total 76
drwx------  9 zbc  zbc   4096 Apr 27 23:03 .
drwxr-xr-x  4 root root    35 Apr 22 20:11 ..
-rw-------  1 zbc  zbc   6370 Apr 27 23:03 .bash_history
-rw-r--r--  1 zbc  zbc     18 Oct 23  2025 .bash_logout
-rw-r--r--  1 zbc  zbc    141 Oct 23  2025 .bash_profile
-rw-r--r--  1 zbc  zbc    376 Oct 23  2025 .bashrc
drwxr-xr-x  3 zbc  zbc     19 Apr 22 20:37 .cache
drwxr-xr-x  3 zbc  zbc     18 Apr 25 12:56 .config
drwxr-xr-x  4 zbc  zbc     40 Apr 23 15:43 gitcage
drwx------  4 zbc  zbc     30 Apr 25 12:54 .local
-rw-r--r--  1 zbc  zbc      0 Apr 25 12:57 PassWordForZbc
drwxr-xr-x  2 zbc  zbc     98 Apr 22 21:15 Programe_ProgressBar_2026_4_22
-rw-r--r--  1 zbc  zbc      0 Apr 27 23:03 test01
----------  1 zbc  zbc      0 Apr 27 23:03 test02
-rw-r--r--  1 zbc  zbc   2116 Apr 25 13:40 test.cpp
drwxr-xr-x  2 zbc  zbc     60 Apr 27 23:01 TESTmulu
drwxr-xr-x 15 zbc  zbc   4096 Apr 25 14:19 .vim
-rw-------  1 zbc  zbc  16890 Apr 26 09:30 .viminfo
-rw-r--r--  1 zbc  zbc  14802 Apr 25 14:19 .vimrc
-rw-r--r--  1 zbc  zbc    180 Apr 25 14:18 .wget-hsts
-rw-r--r--  1 zbc  zbc    188 Jun 13  2025 .zshrc
[zbc@VM-0-9-opencloudos ~]$ sudo touch _test.txt
[sudo] password for zbc: 
Sorry, try again.
[sudo] password for zbc: 
[zbc@VM-0-9-opencloudos ~]$ ls -l _test.txt
-rw-r--r-- 1 root root 0 Apr 28 08:31 _test.txt
[zbc@VM-0-9-opencloudos ~]$ rm -f _test.txt
[zbc@VM-0-9-opencloudos ~]$ ls -al
total 76
drwx------  9 zbc  zbc   4096 Apr 28 08:31 .
drwxr-xr-x  4 root root    35 Apr 22 20:11 ..
-rw-------  1 zbc  zbc   6430 Apr 28 08:31 .bash_history
-rw-r--r--  1 zbc  zbc     18 Oct 23  2025 .bash_logout
-rw-r--r--  1 zbc  zbc    141 Oct 23  2025 .bash_profile
-rw-r--r--  1 zbc  zbc    376 Oct 23  2025 .bashrc
drwxr-xr-x  3 zbc  zbc     19 Apr 22 20:37 .cache
drwxr-xr-x  3 zbc  zbc     18 Apr 25 12:56 .config
drwxr-xr-x  4 zbc  zbc     40 Apr 23 15:43 gitcage
drwx------  4 zbc  zbc     30 Apr 25 12:54 .local
-rw-r--r--  1 zbc  zbc      0 Apr 25 12:57 PassWordForZbc
drwxr-xr-x  2 zbc  zbc     98 Apr 22 21:15 Programe_ProgressBar_2026_4_22
-rw-r--r--  1 zbc  zbc      0 Apr 27 23:03 test01
----------  1 zbc  zbc      0 Apr 27 23:03 test02
-rw-r--r--  1 zbc  zbc   2116 Apr 25 13:40 test.cpp
drwxr-xr-x  2 zbc  zbc     60 Apr 27 23:01 TESTmulu
drwxr-xr-x 15 zbc  zbc   4096 Apr 25 14:19 .vim
-rw-------  1 zbc  zbc  16890 Apr 26 09:30 .viminfo
-rw-r--r--  1 zbc  zbc  14802 Apr 25 14:19 .vimrc
-rw-r--r--  1 zbc  zbc    180 Apr 25 14:18 .wget-hsts
-rw-r--r--  1 zbc  zbc    188 Jun 13  2025 .zshrc
[zbc@VM-0-9-opencloudos ~]$

2.1.2共享目录的需求

为了实现协作，我们必须在公共目录下（如根目录 / 下）创建专门的共享文件夹。 但随之而来的安全隐患是：如何保证在共享目录下，用户只能管理自己的文件，而不能删除他人的文件？

2.2 粘滞位的诞生与作用

为了解决上述"共享与保护"的矛盾，Linux 引入了 粘滞位（Sticky Bit）。

2.2.1核心特征与定义

  • 权限标志位 ：在目录权限的最后一位（Others 的执行位）显示为 t（如果原本有 x 权限）或 T（如果原本没有 x 权限）。
  • 核心功能 ：当一个目录被设置了粘滞位后，该目录下的文件只能由以下三类人删除 ：
    1. 超级管理员（root）。
    2. 该目录的拥有者。
    3. 该文件的拥有者。

2.2.2典型案例：系统的 /tmp 目录

Linux 系统自带的 /tmp 目录就是一个完美的粘滞位应用案例。任何人都可以在 /tmp 下创建临时文件，但由于粘滞位的存在，普通用户无法删除属于其他人的临时文件。 tmp原本的作用就是存放系统产生的各种临时文件。

bash 复制代码 
[root@VM-0-9-opencloudos ~]# cd ..
[root@VM-0-9-opencloudos /]# ls -al
total 20
dr-xr-xr-x  18 root root   256 Apr 28 08:27 .
dr-xr-xr-x  18 root root   256 Apr 28 08:27 ..
-rw-r--r--   1 root root     0 Apr 22 20:10 .autorelabel
lrwxrwxrwx   1 root root     7 Dec 12  2024 bin -> usr/bin
dr-xr-xr-x   5 root root   295 Mar 20 18:13 boot
drwxr-xr-x   2 root root     6 Dec 12  2024 data
drwxr-xr-x  18 root root 13480 Apr 22 20:10 dev
drwxr-xr-x  94 root root  8192 Apr 25 22:10 etc
drwxr-xr-x   4 root root    35 Apr 22 20:11 home
lrwxrwxrwx   1 root root     7 Dec 12  2024 lib -> usr/lib
lrwxrwxrwx   1 root root     9 Dec 12  2024 lib64 -> usr/lib64
drwxr-xr-x   2 root root     6 Dec 12  2024 media
drwxr-xr-x   2 root root     6 Dec 12  2024 mnt
drwxr-xr-x   2 root root     6 Dec 12  2024 opt
dr-xr-xr-x 197 root root     0 Apr 22 20:10 proc
dr-xr-x---   5 root root   216 Apr 27 22:52 root
drwxr-xr-x  35 root root  1160 Apr 22 20:11 run
lrwxrwxrwx   1 root root     8 Dec 12  2024 sbin -> usr/sbin
drwxr-xr-x   2 root root     6 Dec 12  2024 srv
dr-xr-xr-x  12 root root     0 Apr 22 20:10 sys
drwxrwxrwt   8 root root  4096 Apr 28 08:27 tmp #系统自带的临时文件夹
drwxr-xr-x  13 root root   155 Apr 25 12:50 usr
drwxr-xr-x  20 root root  4096 Jul  4  2025 var
[root@VM-0-9-opencloudos /]#

2.3 如何设置粘滞位

使用 chmod 命令，通过 +t 参数为指定目录添加粘滞位：

bash 复制代码 
#赋予目录粘滞位权限
chmod +t [目录名]
bash 复制代码 
[root@VM-0-9-opencloudos /]# mkdir _template
[root@VM-0-9-opencloudos /]# ls -al
total 20
dr-xr-xr-x  19 root root   273 Apr 28 08:34 .
dr-xr-xr-x  19 root root   273 Apr 28 08:34 ..
-rw-r--r--   1 root root     0 Apr 22 20:10 .autorelabel
lrwxrwxrwx   1 root root     7 Dec 12  2024 bin -> usr/bin
dr-xr-xr-x   5 root root   295 Mar 20 18:13 boot
drwxr-xr-x   2 root root     6 Dec 12  2024 data
drwxr-xr-x  18 root root 13480 Apr 22 20:10 dev
drwxr-xr-x  94 root root  8192 Apr 25 22:10 etc
drwxr-xr-x   4 root root    35 Apr 22 20:11 home
lrwxrwxrwx   1 root root     7 Dec 12  2024 lib -> usr/lib
lrwxrwxrwx   1 root root     9 Dec 12  2024 lib64 -> usr/lib64
drwxr-xr-x   2 root root     6 Dec 12  2024 media
drwxr-xr-x   2 root root     6 Dec 12  2024 mnt
drwxr-xr-x   2 root root     6 Dec 12  2024 opt
dr-xr-xr-x 190 root root     0 Apr 22 20:10 proc
dr-xr-x---   5 root root   216 Apr 27 22:52 root
drwxr-xr-x  35 root root  1160 Apr 22 20:11 run
lrwxrwxrwx   1 root root     8 Dec 12  2024 sbin -> usr/sbin
drwxr-xr-x   2 root root     6 Dec 12  2024 srv
dr-xr-xr-x  12 root root     0 Apr 28 08:27 sys
drwxrwxrwx   2 root root     6 Apr 28 08:34 _template #权限全部放开，所有人都可以一删除，这是不可以的。
drwxrwxrwt   7 root root  4096 Apr 28 08:31 tmp 
drwxr-xr-x  13 root root   155 Apr 25 12:50 usr
drwxr-xr-x  20 root root  4096 Jul  4  2025 var
[root@VM-0-9-opencloudos /]# chmod +t _template 
[root@VM-0-9-opencloudos /]# ls -l _template
total 0
[root@VM-0-9-opencloudos /]# ls -al 
total 20
dr-xr-xr-x  19 root root   273 Apr 28 08:34 .
dr-xr-xr-x  19 root root   273 Apr 28 08:34 ..
-rw-r--r--   1 root root     0 Apr 22 20:10 .autorelabel
lrwxrwxrwx   1 root root     7 Dec 12  2024 bin -> usr/bin
dr-xr-xr-x   5 root root   295 Mar 20 18:13 boot
drwxr-xr-x   2 root root     6 Dec 12  2024 data
drwxr-xr-x  18 root root 13480 Apr 22 20:10 dev
drwxr-xr-x  94 root root  8192 Apr 25 22:10 etc
drwxr-xr-x   4 root root    35 Apr 22 20:11 home
lrwxrwxrwx   1 root root     7 Dec 12  2024 lib -> usr/lib
lrwxrwxrwx   1 root root     9 Dec 12  2024 lib64 -> usr/lib64
drwxr-xr-x   2 root root     6 Dec 12  2024 media
drwxr-xr-x   2 root root     6 Dec 12  2024 mnt
drwxr-xr-x   2 root root     6 Dec 12  2024 opt
dr-xr-xr-x 190 root root     0 Apr 22 20:10 proc
dr-xr-x---   5 root root   216 Apr 27 22:52 root
drwxr-xr-x  35 root root  1160 Apr 22 20:11 run
lrwxrwxrwx   1 root root     8 Dec 12  2024 sbin -> usr/sbin
drwxr-xr-x   2 root root     6 Dec 12  2024 srv
dr-xr-xr-x  12 root root     0 Apr 28 08:27 sys
drwxrwxrwt   2 root root     6 Apr 28 08:34 _template 
drwxrwxrwt   7 root root  4096 Apr 28 08:31 tmp 
drwxr-xr-x  13 root root   155 Apr 25 12:50 usr
drwxr-xr-x  20 root root  4096 Jul  4  2025 var
[root@VM-0-9-opencloudos /]#

由此，加上粘滞位之后，所有人都可以读可以写，但是只能删除自己创建的文件。同时删除整个目录的权限集中在拥有者上 ，root无所谓。

这种共享目录的拥有者应该改成root。粘滞位一半也都是给other加，拥有者和所属组都是root。

角色 读写权限 ( r , w r, w r,w) 执行权限 ( x x x) 删除权 (Delete)
文件所有者 正常使用 正常使用 可以删除自己的文件
普通成员 (Group/Others) 正常使用 正常使用 禁止删除他人文件
目录所有者 正常使用 正常使用 可以删除目录下任何文件
Root 绝对控制 绝对控制 无限制

好了，本期内容到此结束，我是此方，我们下期再见。バイバイ！

相关推荐
晨曦夜月2 小时前
进程的五大状态及特殊进程解析
linux·服务器·算法
生而为虫2 小时前
Claude Code 最新版安装教程（Windows/Mac/Linux 全平台） 面向普通用户的 Claude Code 安装与模型接入指南
linux·windows·macos
Sarvartha2 小时前
三目运算符
linux·服务器·前端
liangdabiao2 小时前
乐高摩托车深度报告-致敬张雪夺冠 -基于llm-wiki技术自动化写文章的效果
运维·人工智能·自动化
有浔则灵2 小时前
GORM 日志与调试完全指南：从基础配置到生产实践
服务器·数据库·gorm
vortex52 小时前
Kali Linux 安装与使用 Code-OSS / VSCodium ：VSCode 轻量替代
linux·运维·编辑器
GuokLiu3 小时前
260502-Clawith-Docker安装过程
运维·docker·容器·claw
司南-70493 小时前
Dense结构下的 大模型系统架构研究
服务器·人工智能·后端
.柒宇.3 小时前
AI掘金头条项目部署实践指南
linux·运维·python·fastapi
热门推荐
01要裂开了！ChatGPT要手机号验证了？注册Codex要求验证电话号码怎么办？2026年登陆Codex要手机号验证的解决办法02GitHub 镜像站点03【AI】2026 年具身智能模型和世界模型总结04裂开！ChatGPT 居然开始要手机号验证，附详细解决方法05Codex 接入 DeepSeek API 完整配置文档062026年AI前瞻：量子AI、具身智能与科学发现的新纪元07零基础教你claude code 接入 deepseek V408实测可用｜小米 MiMo 百万亿 Token 免费领，开发者速冲09在Windows 11上安装Docker的踩坑记录10CC-Switch & Claude 基于 Linux 服务器安装使用指南