想象你搬进了一个管理森严的高档小区。每栋楼的门禁系统都贴着一张“三栏九格”的规则表：第一栏写给业主本人的钥匙权限，第二栏写给业主家人的，第三栏写给来访客人的。每一栏又分三格——“看”“改”“进”。这就是 Linux 文件权限模型的缩影：每个文件都有一张三栏九格的门禁表，用 rwx 三把钥匙，标记属主、属组、其他用户各自能做什么。 这套门禁系统看似简单，实则机关重重：数字 4/2/1 是钥匙的编码方式，chmod 是物业修改规则的工具，setuid 是“临时借业主身份”的特殊徽章，ACL 则是为某个特定访客单独开一条绿色通道。本文就用这栋“小区门禁”的故事，带你从零看懂 rwx 权限、特殊权限位、ACL 访问控制与实战排障，让你面对任何一行 -rw-r--r--，都能像看门禁表一样一眼读懂。

岗位关联

掌握文件权限模型是 AI 工程师部署模型服务、管理训练数据的必修课——一次错误的 chmod 777 可能让整个集群裸奔，而规范的 rwx/ACL 设计，能让你在多人协作中既开放又安全。

目录
  1. 可视化演示
  2. 权限基础概念
  3. rwx三种权限的深层含义
  4. 属主属组管理
  5. chmod权限修改
  6. 特殊权限位
  7. ACL访问控制
  8. 权限故障排查
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示rwx九位权限模型、ACL访问控制列表和权限检查决策流程。

本节配有交互动效（进入视口后自动加载，约 3KB）。

rwx九位权限模型 属主权限：Owner的读/写/执行权限位 属组权限：Group的读/写/执行权限位 perm = (rwx)×3 = 9 bits 九位权限表示

权限基础概念

小区物业在每栋楼门口贴了一张门禁规则表，一共三栏九格：第一栏登记业主本人的钥匙权限，第二栏登记业主家人的权限，第三栏登记访客的权限。每栏又分成三小格，分别记录能否“看”（读）、能否“改”（写）、能否“进”（执行）。Linux 里每个文件也贴着这样一张表，就藏在 ls -l 输出的第一列里。

用 ls -l 查看任意文件，第一列是 10 个字符，比如 -rw-r--r--。第一个字符不是权限，而是“建筑类型”标牌：- 表示普通文件，d 表示目录（相当于一栋楼），l 表示符号链接（相当于指路牌）。后面九个字符才是真正的门禁表，按每三位一组，依次对应“属主、属组、其他用户”。

理解这张门禁表的关键，是知道“谁”落在哪一栏。文件的属主（owner）是创建它的业主；属组（group）是业主所在的家庭/部门；其他用户（other）是小区里的所有访客。内核在判定访问权时，先看你是谁，再决定查哪一栏——绝不跨栏查表。

回到门禁的比喻：如果你是小区的访客，门禁表第三栏清清楚楚写着“只能看不能改也不能进”，保安就按这张表放行或拦下。这张表人人可见、处处适用，正是 Unix 权限系统“简单而强大”的根基。

− rw- r– r– ⇒ −⏟类型位 rw-⏟属主 r–⏟属组 r–⏟其他\displaystyle -\ \text{rw-}\ \text{r--}\ \text{r--}\ \Rightarrow\ \underbrace{-}_{\text{类型位}}\ \underbrace{\text{rw-}}_{\text{属主}}\ \underbrace{\text{r--}}_{\text{属组}}\ \underbrace{\text{r--}}_{\text{其他}}
这行式子把 ls -l 的第一列拆成四段：类型位加上三组权限位。看到 rw- 就明白属主能读写但不能执行，r-- 表示只能读。
  1. 类型位第一个字符标识文件类型，- 普通文件、d 目录、l 链接，相当于门禁表左上角的建筑标签
    第一位:− (文件) / d (目录) / l (链接)\displaystyle \text{第一位}: -\ (\text{文件})\ /\ d\ (\text{目录})\ /\ l\ (\text{链接})
  2. 属主三格第二到第四字符，定义文件属主（业主）的读、写、执行权限
    r⏟读 w⏟写 −⏟不执行\displaystyle \underbrace{r}_{\text{读}}\ \underbrace{w}_{\text{写}}\ \underbrace{-}_{\text{不执行}}
  3. 属组三格第五到第七字符，定义文件所属组（家人）的权限
    r⏟读 −⏟不可写 −⏟不可执行\displaystyle \underbrace{r}_{\text{读}}\ \underbrace{-}_{\text{不可写}}\ \underbrace{-}_{\text{不可执行}}
  4. 其他三格第八到第十字符，定义其他用户（访客）的权限
    r⏟读 −⏟不可写 −⏟不可执行\displaystyle \underbrace{r}_{\text{读}}\ \underbrace{-}_{\text{不可写}}\ \underbrace{-}_{\text{不可执行}}

rwx三种权限的深层含义

门禁表的每一格里，r、w、x 三把钥匙的含义，在“文件”和“目录”两种建筑上并不相同。读（r）对文件是“查看内容”，对目录则是“列出楼里住着哪些人”；写（w）对文件是“修改内容”，对目录则是“在楼里新增或删掉房间”；执行（x）对文件是“运行这个程序”，对目录则是“走进这栋楼”。

最容易被忽视的是目录的执行权限：很多人以为目录有了 r 就能 cd 进去，其实 cd 是“走进楼”，需要的是 x。目录的典型权限 755，含义是业主可以进楼并增删房间（rwx），家人和访客可以进楼参观但不能改动（r-x）。

这三把钥匙还有一个巧妙的数字编码：r 记 4 分，w 记 2 分，x 记 1 分。把每栏三个字母的分数相加，就得到一个 0-7 的数字。于是九位字母瞬间压缩成三个数字，rwxr-xr-- 就变成了 754。这是所有运维人员心算权限的基础。

就像门禁卡上每把钥匙对应一个累积分值：有“看”的钥匙加 4 分，有“改”的钥匙加 2 分，有“进”的钥匙加 1 分。物业报"754"三个数字，保安就知道该给哪三栏发什么钥匙——这就是数字权限的由来。

rwxr-xr– ⇒ (4+2+1) (4+0+1) (4+0+0)=754\displaystyle \text{rwxr-xr--}\ \Rightarrow\ (4+2+1)\,(4+0+1)\,(4+0+0) = 754
这套编码把三组权限各合成一位八进制数：7=全部放行，5=可读可执行，4=只读。看到 754 就能立刻还原出门禁表的样子。
  1. 读权限 r查看文件内容，或列出目录中的文件名；对应数字 4
    r=22=4\displaystyle r = 2^{2} = 4
  2. 写权限 w修改文件内容，或在目录中创建/删除条目；对应数字 2
    w=21=2\displaystyle w = 2^{1} = 2
  3. 执行权限 x运行文件，或进入（穿越）目录；对应数字 1
    x=20=1\displaystyle x = 2^{0} = 1
  4. 分段求和每三位字母一组相加，得到一位八进制数，三段合起来就是权限简写
    (4+2+1) (4+0+1) (4+0+0)=754\displaystyle (4+2+1)\,(4+0+1)\,(4+0+0) = 754

属主属组管理

门禁表的第一栏写的是“业主姓名”，第二栏写的是“家庭/部门名称”。这两个名字不是写死的：物业可以办理过户，把文件划给另一个业主或另一个部门。在 Linux 里，办理过户的工具是 chown 和 chgrp。

chown（change owner）用来修改文件的属主和属组，格式是 chown 用户名:组名 文件。把 report.txt 划给 alice 和 dev 组，一条命令：chown alice:dev report.txt。注意，修改属主是“过户”级别的操作，只有 root（物业总管家）才有权办理；但业主本人可以把文件划给同组的家人（修改属组），前提是你属于目标组。

chgrp（change group）是只改属组不改属主的轻量工具。当 AI 团队里一个新同学加入 dev 组，你想把训练日志共享给他，chgrp dev train.log 就够了。日常用 -R 参数可以递归处理目录下所有文件，相当于对整个楼栋的所有房间批量过户。

在处理多人共用的模型目录时，“过户”是一门学问：模型文件通常属于某个服务账号，团队成员通过属组共享读取权。用 chown -R 批量调整归属，比一个个文件手动改高效得多，也让门禁表的第一栏永远指向正确的人。

chown alice⏟新属主 :dev⏟新属组 report.txt⏟目标文件\displaystyle \text{chown}\ \underbrace{\text{alice}}_{\text{新属主}}\ \underbrace{:\text{dev}}_{\text{新属组}}\ \underbrace{\text{report.txt}}_{\text{目标文件}}
这是 chown 的标准语法：冒号前是新的业主，冒号后是新的部门，最后是目标文件。省略冒号及后面部分表示只改属主。
  1. 命令名 chownchange owner 的缩写，负责修改文件的属主与属组
    chown=change owner\displaystyle \text{chown} = \text{change owner}
  2. 属主参数第一个参数指定新的属主用户名，该操作仅 root 可执行，相当于物业才有权过户
    chown alice report.txt\displaystyle \text{chown}\ \text{alice}\ \text{report.txt}
  3. 属组参数冒号后指定新的属组，业主本人若属于目标组也可以修改
    chown alice:dev report.txt\displaystyle \text{chown}\ \text{alice}:\text{dev}\ \text{report.txt}
  4. 递归参数 -R对目录使用 -R 可递归修改其中所有文件的归属
    chown −R alice:dev /data\displaystyle \text{chown}\ -R\ \text{alice}:\text{dev}\ /\text{data}

chmod权限修改

门禁表定下来之后，业主经常需要调整规则：新招了一个实习生，只给他“看”的权限；或者把某个目录的权限放宽给整个团队。Linux 提供 chmod（change mode）来改权限，它有两种用法：数字模式像“直接填表”，符号模式像“口头下指令”。

数字模式最常用，chmod 755 script.sh 表示：属主 rwx（7），属组 r-x（5），其他 r-x（5）——也就是业主全权，家人和访客只能看和进。符号模式则用字母组合表达增量修改：chmod u+x script.sh 给属主加上执行权限，chmod g-w script.sh 去掉属组的写权限，chmod a+r 让所有人都能读。

新建文件时，默认权限也不是随机的，而是由 umask 决定。umask 像物业的“默认门禁模板”：文件默认按 666 减掉 umask，目录按 777 减掉 umask。umask 022 意味着新文件默认 644、新目录默认 755——既保证业主可写，又避免对所有人开放写权限。

chmod 是权限操作的“日常主力”：部署脚本时 chmod +x 给执行权限，写配置文件时 644 保证安全，共享目录用 775 让组内可写。记住“数字模式填表、符号模式微调”，大多数权限需求都能一句话搞定。

chmod 755 script.sh ⇒ 7⏟rwx 5⏟r-x 5⏟r-x\displaystyle \text{chmod}\,755\ \text{script.sh}\ \Rightarrow\ \underbrace{7}_{\text{rwx}}\ \underbrace{5}_{\text{r-x}}\ \underbrace{5}_{\text{r-x}}
数字模式把三个数字直接翻译成三栏权限：7 是全钥匙，5 是读+执行，4 是只读。这是 Linux 中使用频率最高的命令之一。
  1. 命令名 chmodchange mode 的缩写，修改文件或目录的权限位
    chmod=change mode\displaystyle \text{chmod} = \text{change mode}
  2. 数字模式跟随三个 0-7 的数字，分别对应属主、属组、其他三栏权限
    7=4+2+1⇒rwx,5=4+0+1⇒r-x\displaystyle 7=4+2+1\Rightarrow\text{rwx},\quad 5=4+0+1\Rightarrow\text{r-x}
  3. 符号模式用 u/g/o 指代三栏，配合 +、-、= 与 rwx 字母做增量修改
    chmod u+x, g−w script.sh\displaystyle \text{chmod}\ u+x,\ g-w\ \text{script.sh}
  4. umask 计算新文件 = 666 - umask，新目录 = 777 - umask
    umask 0022 ⇒ 666−022=644\displaystyle \text{umask}\ 0022\ \Rightarrow\ 666-022=644

特殊权限位

普通的三栏九格之外，门禁系统还藏着三个特殊徽章，它们不是给某个人而是给“整个门禁机制”用的。第一个徽章是 setuid（数字 4）：它让普通用户执行某个程序时，临时获得文件属主的身份。经典例子是 passwd——普通用户改密码需要写 /etc/shadow，而该文件只有 root 能写，setuid 让 passwd 程序“临时借来 root 身份”完成修改。

第二个徽章是 setgid（数字 2）：在可执行文件上，它让进程临时获得属组身份；在目录上更常用——目录设置了 setgid 后，里面新建的文件会自动继承目录的属组，而非创建者的默认组。这对团队共享目录极其有用，大家新建的文件自然归同一个组。

第三个徽章是粘滞位 sticky（数字 1）：它只对目录有意义，表示“只有文件属主、目录属主或 root 才能删除目录里的文件”。最典型的例子是 /tmp（权限 1777）：所有用户都能在里面创建临时文件，但谁也不能删除别人的文件——相当于小区里人人可用的公共储物柜，但每个格子只有物主能打开。

这三个徽章是“规则之上的规则”：setuid 让普通用户能安全地提权完成特定任务，setgid 让团队目录自组织地共享归属，sticky 让公共目录在开放中保持秩序。理解它们，你就能解释很多“为什么这个目录看起来怪怪的”的现象。

4⏟setuid 7 5 5⏟基础权限 ⇒ rwsr-xr-x\displaystyle \underbrace{4}_{\text{setuid}}\ \underbrace{7\ 5\ 5}_{\text{基础权限}}\ \Rightarrow\ \text{rwsr-xr-x}
特殊权限位是基础权限前的第四位数字：4=setuid，2=setgid，1=sticky。设置后权限字符串中的 x 会变成 s 或 t。
  1. setuid（4）执行时进程临时获得文件属主身份，权限串中属主 x 变为 s
    rws ⇒ s=setuid 已生效\displaystyle \text{rws}\ \Rightarrow\ s = \text{setuid 已生效}
  2. setgid（2）文件上临时获得属组身份；目录上让新文件继承目录属组
    chmod 2755 shared_dir\displaystyle \text{chmod}\ 2755\ \text{shared\_dir}
  3. sticky（1）目录内仅文件属主、目录属主与 root 可删除文件，权限串末尾为 t
    chmod 1777 /tmp ⇒ drwxrwxrwt\displaystyle \text{chmod}\ 1777\ /\text{tmp}\ \Rightarrow\ \text{drwxrwxrwt}
  4. 特殊位与基础权限叠加特殊位数字写在基础权限数字之前，组成四位数字
    4755 = 4⏟setuid+755⏟基础权限\displaystyle 4755\ =\ \underbrace{4}_{\text{setuid}} + \underbrace{755}_{\text{基础权限}}

ACL访问控制

传统的三栏九格有个先天局限：它只能区分“业主、家人、访客”三类人。可现实中，你往往想给某个特定访客单独开权限——比如给审计员 bob 只读权，给外包团队 r-x，但不改变文件的属主和属组。这时就需要 ACL（Access Control List，访问控制列表），它是门禁系统的“白名单扩展”。

ACL 的核心思路是：在传统三栏之外，额外维护一张“特定人员规则表”，专门记录某个用户或某个组对文件的细粒度权限。设置命令是 setfacl，查看命令是 getfacl。给 bob 读写权限：setfacl -m u:bob:rwx report.txt；收回：setfacl -x u:bob report.txt。

文件一旦设置了 ACL，ls -l 输出的权限串末尾会出现一个 + 号，提醒你“这里还有隐藏规则”。另外，ACL 还支持默认 ACL（-d 选项）：给目录设置默认 ACL 后，里面新建的文件会自动继承这套规则，相当于物业在楼栋入口处贴了一张“对所有新住户生效”的补充规定。

ACL 是多人协作场景的救命稻草：它让你不必为了给某个同事开权限而修改文件属主，也不用粗暴地放开到 777。一张 getfacl 输出，就能看清所有“特别通行证”的完整清单。

setfacl −m u⏟用户类型:alice⏟用户名:rwx⏟权限 report.txt⏟目标文件\displaystyle \text{setfacl}\ -\text{m}\ \underbrace{u}_{\text{用户类型}}:\underbrace{\text{alice}}_{\text{用户名}}:\underbrace{\text{rwx}}_{\text{权限}}\ \underbrace{\text{report.txt}}_{\text{目标文件}}
setfacl 的条目格式是“类型：名字：权限”。u 代表用户，g 代表组，o 代表其他。权限可以写 rwx 字母，也可以写数字。
  1. 命令名 setfaclset file access control list，设置文件的 ACL 规则
    setfacl=set file ACL\displaystyle \text{setfacl} = \text{set file ACL}
  2. 选项 -mmodify，新增或修改一条 ACL 规则
    −m 条目\displaystyle -m\ \text{条目}
  3. 条目格式u:用户名：权限 为特定用户授权，g:组名：权限 为特定组授权
    u:alice:rwx\displaystyle u:\text{alice}:\text{rwx}
  4. 查看与默认 ACLgetfacl 查看全部规则；-d 设置默认 ACL，新文件自动继承
    getfacl report.txt,setfacl −d−m u:bob:r-x /data\displaystyle \text{getfacl}\ \text{report.txt},\qquad \text{setfacl}\ -d -m\ u:\text{bob}:\text{r-x}\ \text{/data}

权限故障排查

门禁卡刷不开门时，保安会按固定流程排查：先看你是业主还是家人还是访客，再看看门禁表对应栏位的钥匙是否匹配。Linux 内核的权限判定同样遵循严格的匹配顺序：先判断你的 uid 是否等于文件属主，是则查属主位；否则判断你的组是否属于文件属组，是则查属组位；两者都不满足才落到“其他用户”位。

最常见的排障场景是"Permission denied"。第一步用 ls -l 查看基础权限，确认身份落在哪一栏；第二步用 getfacl 检查是否有 ACL 规则覆盖；第三步检查父目录——文件权限再宽松，如果父目录没有 x 权限，你依然进不去。目录权限在整个路径上是逐级叠加的，任何一个环节缺失都会导致访问失败。

新文件权限“不对劲”时，优先查 umask。系统里每个 shell 进程都有自己的 umask 值，它决定了新建文件的默认权限。排查命令还有 stat：可以查看文件的完整时间戳与权限数字；namei -l 可以沿路径逐层检查每一级目录的权限，快速定位“卡在哪一层楼”。

排障的终点往往是“最小权限原则”：给每个角色恰如其分的权限，不多一分写权限，不少一分执行权限。就像高级小区的安保哲学——门禁不是为了锁死所有人，而是让每个人都能顺畅到达自己的房间，同时进不了别人的。这才是权限模型真正的工程智慧。

匹配顺序: 属主 → 属组 → 其他,ACL 优先于传统权限位\displaystyle \text{匹配顺序}:\ \text{属主}\ \rightarrow\ \text{属组}\ \rightarrow\ \text{其他},\qquad \text{ACL 优先于传统权限位}
内核判定权限时按属主、属组、其他的顺序，命中即停；若设置了 ACL，则优先查 ACL 规则，再回退到基础权限位。
  1. 身份匹配内核先比较 uid 是否等于文件属主，等于则使用属主权限位
    uid=文件属主 ⇒ 查属主位\displaystyle \text{uid} = \text{文件属主}\ \Rightarrow\ \text{查属主位}
  2. 命中即停属主不匹配则检查属组，仍不匹配才落到其他用户位，绝不叠加
    组ID∈文件属组 ⇒ 查属组位\displaystyle \text{组ID} \in \text{文件属组}\ \Rightarrow\ \text{查属组位}
  3. ACL 优先文件带 ACL 规则时，先按 ACL 匹配特定用户，再回退传统位
    ACL 命中 ⇒ 按 ACL 授权\displaystyle \text{ACL 命中}\ \Rightarrow\ \text{按 ACL 授权}
  4. umask 校验新文件权限异常时，用 666 减 umask 验证默认值是否符合预期
    666−umask(0022)=644\displaystyle 666 - \text{umask}(0022) = 644

AI 应用场景

模型服务配置文件权限加固

阶段：模型部署与运维

解决的问题：AI 模型服务涉及 API Key、模型权重、配置文件等敏感资产。传统做法是图省事直接 chmod 777，导致任何进程都能读取密钥；规范的 rwx 设计让配置 600、模型目录 750、日志 640，既保证服务进程可读，又封死其他用户的读写路径。

具体案例：部署 KServe/Triton 推理服务时，将 config.pbtxt 设为 640（root:aimodels），模型权重目录设为 750，/var/log/ai 日志目录设为 640 并配合 chgrp 划给日志采集组。排查时用 getfacl 确认每个服务账号的精确权限。

多人训练数据集的 ACL 授权

阶段：数据管理与准备

解决的问题：一个训练数据集往往有数据科学家、标注团队、审计角色三类参与者，需求分别是读写、只读+执行、纯只读。传统三栏权限只能区分“属主/属组/其他”，无法给特定角色单独授权；ACL 可以在不改变属主的前提下精准放权。

具体案例：数据集目录 /data/train_set 属主为数据负责人，用 setfacl -m g:annotators:r-x /data/train_set 给标注组只读+进入权限，用 setfacl -m u:auditor:r-- /data/train_set 给审计员纯只读权限，并用 -d 设置默认 ACL 让新增文件自动继承。

Web 模型服务发布目录权限设计

阶段：服务发布与上线

解决的问题：Web 服务需要读取模型文件，但不应有写权限；多人发布时还要防止互相覆盖。传统权限难以兼顾“共享读写”与“防误删”，setgid 加 sticky 位正好解决这个矛盾。

具体案例：发布目录 /srv/models 使用 chown root:deploy /srv/models && chmod 2775 /srv/models，setgid 让所有发布者新建的文件自动归属 deploy 组；配合 /srv/models/uploads 设置 1777，保证多人上传临时模型时谁也不能删别人的文件。

Python 演示

python46 行
#!/usr/bin/env python3"""模拟 Linux 文件权限九位模型: 用位运算判定谁能访问""" R, W, X = 4, 2, 1            # 读/写/执行 三种钥匙的编码, 对应 rwx 数字表示法OWNER, GROUP, OTHER = 0, 1, 2  def parse_mode(mode_str):    # 'rwxr-xr--' -> ['rwx', 'r-x', 'r--'], 把九位门禁规则切成三栏    return [mode_str[0:3], mode_str[3:6], mode_str[6:9]]  def to_value(bits):    # 把一栏字母转成数字, 如 'r-x' -> 4+0+1 = 5    v = 0    if bits[0] == 'r':        v += R    if bits[1] == 'w':        v += W    if bits[2] == 'x':        v += X    return v  def can_access(mode_str, identity, action):    # 身份: 0/1/2 对应属主/属组/其他; 动作: 'r'/'w'/'x'    key = {'r': R, 'w': W, 'x': X}[action]    seg = parse_mode(mode_str)[identity]    return bool(to_value(seg) & key)   # 位与运算, 检查钥匙是否在门禁卡里  def main():    mode = 'rwxr-xr--'       # 等价于 chmod 754: 属主可写, 属组/其他只读    test = [        ('owner', OWNER, 'w'),   # 属主想写 -> ALLOW        ('group', GROUP, 'w'),   # 属组想写 -> DENY        ('other', OTHER, 'r'),   # 其他想读 -> ALLOW        ('other', OTHER, 'x'),   # 其他想执行 -> DENY    ]    for name, ident, act in test:        ok = can_access(mode, ident, act)        print('%-5s %s -> %s' % (name, act, 'ALLOW' if ok else 'DENY'))  if __name__ == '__main__':    main()
目的：用位运算实现 Linux 内核的权限判定逻辑，输入九位权限字符串，输出不同身份对文件各动作的允许/拒绝结论。
  1. R, W, X = 4, 2, 1三把钥匙的编码，与 chmod 的数字表示法完全一致
  2. return [mode_str[0:3], mode_str[3:6], mode_str[6:9]]把九位门禁规则按三栏切开，对应属主/属组/其他
  3. if bits[0] == 'r': v += R该格是 r 就记 4 分，逐格累加得到本栏数字
  4. return bool(to_value(seg) & key)位与运算：key 对应的钥匙位存在即放行，否则拒绝
  5. for name, ident, act in test:逐条模拟“谁想干什么”，验证内核的命中即停逻辑

常见误区

误区我一直以为目录权限里的 r 就是允许进入，所以曾把目录设成 444，结果还是 `Permission denied`，完全想不通。

正解进入目录（穿越路径）需要的是 x 执行权限。r 只允许你“看到目录里有哪些名字”，但保安不会放你进门。cd 需要 x，ls 需要 r，在目录里创建文件需要 w。所以目录常用 755 而非 444——就像门禁读卡器能读到访客名单，但你没有 x 钥匙就进不了楼。

为何常见：人们把“文件读权限=查看内容”直接套到目录上，忽略了目录的本质是“路径查找结构”，执行权限才对应“穿过”这个动作。

误区服务器上一报权限错误，我的第一反应就是 `chmod 777`，简单粗暴，反正所有人就都能访问了。

正解777 等于把门禁表三栏全部放行，任何用户都能读改写。一旦服务器被入侵，配置文件、密钥、模型权重全部裸奔，这是安全上的黑洞。正确做法是从 644/755 起步，按“最小权限原则”逐级加；需要给特定人授权时，用 ACL 精准放行，而不是对全世界开放。

为何常见：权限报错信息不直观，新手图省事想“一劳永逸”，没意识到 777 是把门禁卡复制给全小区每一个人。

误区反正都是改权限的命令，chmod 改权限，chown 应该也是改权限的吧？两个命令经常混着用。

正解chmod（change mode）改的是 rwx 权限位，即“谁能看、谁能改、谁能进”；chown（change owner）改的是文件的属主和属组，即“门禁表第一栏登记的是谁”。chown 改属主需要 root 权限，而 chmod 属主自己就能执行。一个是改规则，一个是过户，完全是两件事。

为何常见：两个命令缩写相近、使用场景重叠，又都需要在文件上操作，初学者极易混淆。

误区我给 shell 脚本设置了 setuid（4755），希望普通用户执行时获得 root 权限，但运行后还是普通权限，为什么？是不是系统坏了？

正解Linux 内核出于安全考虑，明确忽略解释型脚本（shebang 文件）上的 setuid 位，只有编译后的二进制可执行文件的 setuid 才生效。想让脚本以特定身份运行，应该用 sudo 规则精确控制，而不是依赖 setuid。把 setuid 放到脚本上是无效而且危险的做法。

为何常见：文档里的 setuid 示例几乎都是 passwd 之类的二进制程序，新手把结论随意推广到所有“可执行文件”，忽略了脚本与二进制的本质差异。

误区`ls -l` 输出 `-rw-r--r--`，我看到属组只有读权限，那组里的 bob 肯定不能写文件。

正解当文件设置了 ACL 时，ls -l 权限串末尾会出现一个 + 号，比如 -rw-r--r--+。此时显示的只是“基础权限”，真正的授权规则要用 getfacl 查看。ACL 可以给某个特定用户单独开写权限，且不改变文件的属主和属组——就像门禁表之外还有一张隐藏的白名单。

为何常见：ls -l 是最高频查看命令，人们默认它展示了权限的全貌，忽略了 ACL 这个扩展机制的存在。

面试题

Q1. 执行 ls -l 输出 -rw-r--r--，该文件的权限数字表示是？

单选题 · easy

  • A.644← 正确答案
  • B.754
  • C.777
  • D.600

答案：A。rw- 为 4+2=6，两个 r-- 各为 4，合起来是 644。就像门禁表三栏分别记分：属主 6 分、属组 4 分、其他 4 分。754 对应 rwxr-xr--，777 对应全员 rwx，600 对应仅属主读写。

Q2. 想进入一个目录（执行 cd），至少需要该目录的哪个权限？

单选题 · easy

  • A.读权限 r
  • B.写权限 w
  • C.执行权限 x← 正确答案
  • D.三个权限全部需要

答案：C。进入目录是“穿过楼门”的动作，对应 x 执行权限。r 只允许列出目录内容，w 允许增删文件，都不能让你走进楼。这正是目录权限与文件权限最大的差异点。

Q3. 对文件执行 chmod 755 file.sh 之后，下列说法正确的是？

多选题 · mid

  • A.属主拥有 rwx 权限← 正确答案
  • B.属组拥有 r-x 权限← 正确答案
  • C.其他用户拥有 rw- 权限
  • D.属主拥有 rw- 权限

答案：AB。755 拆开是 7/5/5，对应属主 rwx、属组 r-x、其他 r-x。就像物业给三栏分别配钥匙：业主全钥匙，家人和访客只有看和进。选项 C 的 rw- 是 6，D 的 rw- 对应 6，均不正确。

Q4. 普通用户 alice 想把文件 /data/report.txt 的属主改为 bob，以下说法正确的是？

单选题 · mid

  • A.只有 root 能修改文件属主← 正确答案
  • B.alice 自己是属主，可以直接修改
  • C.bob 同意即可修改
  • D.dev 组内成员都可以修改

答案：A。修改属主是“产权过户”级别的操作，只有 root（物业总管家）有权办理。文件属主可以修改文件的权限位（chmod），但不能把自己的“业主身份”转给别人。这正是 chown 需要 root 权限的原因。

Q5. 粘滞位（sticky bit）最典型的应用场景是哪个目录？

单选题 · mid

  • A./tmp← 正确答案
  • B./etc
  • C./usr/bin
  • D./var/log

答案：A。/tmp 权限为 1777，所有用户都能创建临时文件，但只有文件属主、目录属主或 root 能删除别人的文件。这就像公共储物柜：人人可放东西，但每个人的格子只有自己打得开。/usr/bin 是系统命令目录，/etc 是配置文件目录。

Q6. 关于 setuid 特殊权限位，下列说法正确的是？

多选题 · hard

  • A.数字表示为 4← 正确答案
  • B.使普通用户执行程序时临时获得文件属主身份← 正确答案
  • C.对 shell 脚本同样生效
  • D.常见于 passwd 命令← 正确答案

答案：ABD。setuid 数字为 4，效果是执行时“临时借来属主身份”，passwd 是经典例子——普通用户借此写 /etc/shadow。但 Linux 内核出于安全考虑会忽略脚本上的 setuid 位，只有二进制程序才生效，因此 C 错误。

Q7. 系统 umask 为 022，此时新建的普通文件默认权限是？

单选题 · mid

  • A.755
  • B.644← 正确答案
  • C.622
  • D.666

答案：B。普通文件的默认基数是 666，减去 umask 022 得到 644（666-022=644）。目录的基数是 777，所以新目录为 755。这就像物业的“默认门禁模板”：业主可写，其他人只能读和进。

Q8. 想查看文件 report.txt 的 ACL 信息，以下哪些操作是可行的？

多选题 · hard

  • A.执行 getfacl report.txt← 正确答案
  • B.执行 setfacl -x report.txt
  • C.执行 ls -l report.txt 并观察末尾是否有 +← 正确答案
  • D.执行 getfattr report.txt

答案：AC。getfacl 是查看 ACL 的标准命令；ls -l 也能辅助判断——设置过 ACL 的文件权限串末尾会出现 + 号。setfacl -x 是删除 ACL 条目的命令，getfattr 用于查看扩展属性而非 ACL，两者都不对。

Q9. rwx 三把钥匙对应的数字编码正确的是？

单选题 · easy

  • A.r=1, w=2, x=4
  • B.r=4, w=2, x=1← 正确答案
  • C.r=2, w=4, x=1
  • D.r=4, w=1, x=2

答案：B。r=4、w=2、x=1，对应二进制位 100/010/001 的权重。7=rwx、5=r-x、4=r-- 都由此推导。这是所有 chmod 心算的基础，就像门禁钥匙的记分规则一样需要牢记。

Q10. 一个用户既不是文件的属主，也不属于文件属组，他能否读文件取决于？

单选题 · mid

  • A.其他用户（other）权限位← 正确答案
  • B.属主权限位
  • C.ACL 一定优先且必然放行
  • D.属组权限位

答案：A。内核按“属主→属组→其他”的顺序匹配身份，命中即停。该用户两栏都不匹配，只能落到第三栏“其他用户”权限位。若有 ACL 规则，则优先按 ACL 判定具体用户，但 ACL 不必然放行，因此 C 错误。