权限 · XB 现场笔记

umask 过滤新建权限，默认 ACL 会改变规则

Sat, 09 Oct 2027 00:00:00 +0000

进程的 umask 在普通模式位创建规则下，为新文件和目录移除权限位。应用先提供请求模式，掩码再限制这份请求。它既不是完整访问策略，也不会重写所有既有文件。如果父目录具有默认访问控制列表，创建计算方式还会改变，因此只检查进程掩码，可能无法准确预测最后得到的权限。排查时需要同时看到应用请求和目录环境。

坏掉的样子

没有默认 ACL 时，普通权限结果是请求模式与 umask 按位取反后的值进行按位与。例如请求 0666、掩码 0022，得到 0644。这个计算不是算术减法：相同掩码下请求 0600，仍然得到 0600。应用没有请求执行权限时，宽松掩码也不会主动添加执行位；掩码负责移除，而不是凭空授予应用未请求的普通权限。

限制严格的 umask 不会修复已经存在的全员可写文件。打开并截断该文件，会改变内容，却保留既有模式。后续 chmod 也可以不受当前掩码限制地扩大权限。因此，把 umask 当作权限永远不能超过的上界，会遗漏既有文件与之后权限修改两类情况。必须区分文件首次创建，以及此后围绕同一 inode 发生的操作。

父目录具有默认 ACL 时，Linux 从它派生新对象的访问 ACL，再按应用请求模式限制权限，不再按普通方式应用进程 umask。因此，即使创建者掩码是 0077，共享目录里仍可能生成组可访问文件。遇到与预期不同的模式时，应检查继承的 ACL，而不能只看到严格掩码就断言内核没有遵守权限设置。

快速验证

把脚本保存为 mask.py，在安装 Python 3 和 setfacl 的 Linux 环境中运行 python3 mask.py。临时目录所在文件系统必须支持默认 ACL。实测使用 Python 3.11.2、acl 2.3.1，以及通过 TMPDIR 选择的独立 ext4 卷。最初 tmpfs 环境拒绝设置默认 ACL，因此完整实验随后在 ext4 上重新执行：

from pathlib import Path
from tempfile import TemporaryDirectory
import os,stat,subprocess

def create(path,requested):
 fd=os.open(path,os.O_WRONLY|os.O_CREAT|os.O_EXCL,requested);os.close(fd)
def mode(path):return stat.S_IMODE(path.stat().st_mode)
previous=os.umask(0o022)
try:
 with TemporaryDirectory(prefix='xbcatm-umask-') as directory:
 root=Path(directory)
 data=root/'data';create(data,0o666);assert mode(data)==0o644
 executable=root/'executable';create(executable,0o777);assert mode(executable)==0o755
 private=root/'private';create(private,0o600);assert mode(private)==0o600
 folder=root/'folder';folder.mkdir(mode=0o777);assert mode(folder)==0o755
 assert 0o600&~0o022==0o600 and 0o600-0o022!=0o600
 print('without default ACL: requested mode AND NOT umask; 0666 becomes 0644, 0777 becomes 0755')
 os.umask(0o077)
 strict=root/'strict';create(strict,0o666);assert mode(strict)==0o600
 existing=root/'existing';create(existing,0o666);existing.chmod(0o666)
 fd=os.open(existing,os.O_WRONLY|os.O_TRUNC);os.close(fd)
 assert mode(existing)==0o666
 print('restrictive mask leaves an existing 0666 file unchanged; chmod can widen permissions later')
 acl_folder=root/'acl';acl_folder.mkdir()
 subprocess.run(['setfacl','-d','-m','u::rwx,g::rwx,o::---',str(acl_folder)],check=True)
 inherited=acl_folder/'inherited';create(inherited,0o666)
 restricted=acl_folder/'restricted';create(restricted,0o600)
 assert mode(inherited)==0o660 and mode(restricted)==0o600
 print('with default ACL and umask 0077: request 0666 yields 0660; request 0600 still yields 0600')
 status=dict(line.split(':',1) for line in Path('/proc/self/status').read_text().splitlines() if ':' in line)
 assert int(status['Umask'].strip(),8)==0o077
 print('/proc/self/status observes this process mask without temporarily changing it')
finally:os.umask(previous)

掩码为 0022、没有继承默认 ACL 时，请求 0666 得到 0644 文件；请求 0777，普通文件和目录均得到 0755；请求 0600 则仍为 0600。脚本还检查算术减法会对最后一种请求产生不同结果，直接暴露常见计算错误。这些结果说明，需要理解位操作，而不是把八进制权限数字当作普通额度相减。

改为掩码 0077 后，新文件请求 0666，最终得到 0600。另一个文件被明确 chmod 为 0666，随后以截断方式打开，但没有创建操作，其模式保持 0666。这个对照区分首次创建与既有 inode 上的后续操作，而不是假定每次 open 都重新套用创建策略。严格掩码无法替代对存量权限的检查。

接着，脚本给父目录设置默认 ACL：所属用户和组拥有完整权限，其他用户没有权限。进程掩码仍为 0077，新文件请求 0666，却得到 0660。继承 ACL 在严格掩码下保留组读写权限，同时应用请求排除了执行权限。结果来自实际文件状态检查，不是只看 setfacl 命令执行成功就推测新文件行为。

同一目录中另一个文件请求 0600，结果仍为 0600。默认规则不会添加请求模式排除的权限。这两种请求一起验证了默认 ACL 对普通掩码规则的例外，也验证应用显式请求仍然参与限制。只观察较宽的一种结果，容易误以为 ACL 可以忽略应用的所有权限请求，因此必须保留这个对照。

脚本从 /proc/self/status 读取 Umask，确认进程掩码仍为 0077，在 finally 中恢复原值并清理临时目录。如果文件系统无法设置 ACL，命令会失败，不会跳过核心例外后声称完整通过。前一次环境失败与之后完整执行的结果分别保留，避免把环境能力缺失误写成契约已经验证。

在正确层级应用创建策略

umask 会随正常进程创建继承，并在执行另一个程序后保留。服务或命令应通过真实启动路径设置它。无关终端的掩码不会追溯改变已经运行的进程，shell 配置文件也只有被启动链读取时才生效。需要验证的是最终创建文件的进程状态，而不是另一个方便观察的控制终端。

对于共享相关文件系统状态的线程，umask 是进程范围的设置。为了读取旧值而临时改动它，可能干扰同时发生的文件创建。Linux 上读取 proc 状态字段可以避免这种修改。应用如果必须创建私有文件，应请求足够严格的权限，并核对真实存储环境，不能依赖一次短暂改掩码覆盖所有并发创建行为。

还应一起检查父目录访问权限、所有权、ACL 和最终文件权限。0660 文件位于不可访问父目录中时，组用户并不会自动获得完整访问路径；模式位也不能单独描述所有命名 ACL 条目。本实验验证创建结果，端到端访问则需要让预期身份沿完整路径实际尝试。权限数字正确，只是整条访问条件中的一部分。

来源

umask(2)，创建掩码、继承、默认 ACL 交互与 proc 检查，已核验 2026-09-12。
acl(5)，默认 ACL 继承与请求模式对权限的约束，已核验 2026-09-12。
open(2)，创建模式与打开或截断既有文件，已核验 2026-09-12。

Setuid 在 exec 时改变有效身份

Sat, 02 Oct 2027 00:00:00 +0000

Linux 可执行文件上的 setuid 位，可以在 exec 成功时把进程的有效用户 ID 改为文件属主的 ID。它不会把进程全部凭据都替换成属主的登录身份。特权辅助程序因此能够代表另一个账户完成受控操作，但输入处理和特权持续时间都会成为安全边界的一部分。模式位本身既不能证明身份转换已经发生，也不能证明这个辅助程序安全。

文件位与进程凭据分开观察

通常的 set-user-ID 转换会改变有效 UID，再将结果复制到保存的 set-user-ID；真实 UID 保持不变。组凭据是另一套状态：setuid 不会自动装入文件属主的附加组。Linux 还存在文件系统身份和能力集合，因此真实、有效与保存 UID 是有用的观察，却不是权限的完整描述。不能看到有效身份变成某个账户，就假设已经拥有该账户登录会话的全部上下文。

应检查实际部署的文件，不要推断整个发行版都采用同一权限。用于修改密码的特权程序，在容器或定制镜像里可能有不同安装方式。属主执行位位置的小写 s 表示同时具备 setuid 和属主执行位，大写 S 则表示存在 setuid 但没有那个执行位。两种显示都不能替代属主核验、目标文件核验，以及对真实启动上下文的检查。

执行环境可以抑制转换

Linux 文档列出了 no_new_privs、nosuid 挂载和被跟踪等条件，它们可能抑制特权转换；某些文档记录的组合也可能直接让执行失败。文件能力同样受到执行约束。不能为了让演示成功，就关闭这些保护。应确定目标路径与调用进程实际适用哪些政策，如实说明限制，而不是把受保护环境当作必须修复的故障。

Linux 忽略解释器脚本上的 set-user-ID 与 set-group-ID 位。因此，把原生辅助程序改成脚本并保留模式，不会保留原先的提权行为。给通用解释器增加特权也不是安全替代方案。特权程序另外启动的可执行文件，还可能主动重置凭据，所以运行独立的 id 命令，不一定忠实显示原辅助程序内部的身份。观测点必须与要验证的进程一致。

降权需要完整设计

setuid 系统调用不同于文件上的模式位。具有足够权限的调用者可以改变真实、有效和保存 UID；非特权调用者能够进行的转换范围更窄。若仍保留允许恢复的保存身份，seteuid 可以支持有效 UID 的可逆切换。无论哪种调用，都必须先检查返回值，再确认状态，不能因为进程原来拥有高权限，就假设降权调用不会失败。

去掉保存 UID 只是永久放弃权限的一部分。附加组、保留能力、已经打开的特权描述符、命名空间和后续执行路径，同样需要考虑。一条 setuid 调用不是通用降权配方，正确顺序取决于程序原有的凭据和资源。安全敏感的辅助程序需要针对设计进行审查，不能把文章里的身份概念直接复制成未经验证的安全实现。

坏掉的样子

带有 s 的模式显示可能掩盖被抑制的转换；另一方面，权限过大的辅助程序也可能通过不安全的路径搜索、用户选择的配置文件等接口泄露真实能力。动态加载器在安全执行模式下会限制危险环境变量，却不会替应用验证输入。应避免用 shell 字符串拼接命令，并明确辅助程序允许访问哪些文件、接收哪些参数和执行哪些操作。

能力机制可以缩小某项授予，例如只允许绑定特权端口，但不会让其他权限全部消失。账户已有的访问权和其他能力仍然存在，能力边界集合与 securebits 还会限制 root 行为。同样，命名空间内部的 root 不等于宿主 root，但映射到普通用户的权限仍然有实际作用。套接字激活可以交付已经打开的监听描述符，却不能免除接收请求的服务本身应承担的安全要求。

快速验证

在具备 Bash、GNU stat、util-linux findmnt、libcap getcap 和 Python 3 的 Linux 环境运行下面完整代码。它只读取一个已安装文件的元数据，以及新 Python 进程自己的凭据状态，不执行 passwd，不改变权限或身份，不挂载文件系统，也不创建命名空间。明确写出目标路径，是为了避免搜索结果意外选中另一个程序；缺少依赖时应补齐正常测试环境，而不是删掉失败检查继续宣称完成。

BASH_ENV= bash --noprofile --norc <<'BASH'
set -eu
target=/usr/bin/passwd
test -f "$target"
stat -c 'mode=%A numeric=%a owner=%u group=%g path=%n' "$target"
findmnt --noheadings --output TARGET,VFS-OPTIONS --target "$target"
getcap -v "$target"
python3 - <<'PYTHON'
import os
from pathlib import Path

status = dict(line.split(':', 1) for line in
 Path('/proc/self/status').read_text().splitlines() if ':' in line)
uids = tuple(map(int, status['Uid'].split()))
gids = tuple(map(int, status['Gid'].split()))
assert uids[:3] == os.getresuid()
assert gids[:3] == os.getresgid()
assert len(uids) == len(gids) == 4
for key in ['Uid', 'Gid', 'Groups', 'NoNewPrivs', 'CapEff', 'CapBnd']:
 print(f'{key}:{status[key]}')
print('PASS: inspected metadata and current credentials; target not executed')
PYTHON
BASH

输出应包含实际模式、数字属主和属组、所在文件系统的挂载选项，以及目标的文件能力列表。没有文件能力，不等于没有 setuid 位；有 setuid 位，也不代表一定存在文件能力。Python 断言把 UID 与 GID 的前三个状态字段分别和对应系统调用结果比较；第四个字段代表文件系统身份。观察当前检查进程的状态，也不能推导尚未运行目标的执行结果。

最后的通过提示只证明这项只读检查完成。不同主机上的值可以不同，实验没有硬编码预期 root 身份，也没有演示提权、不可逆降权或抗攻击能力。这些结论需要另外获准的临时安全测试，以及真实辅助程序内部的观察，不能通过削弱宿主保护来取得一个看起来成功的结果。

来源

Linux execve，有效身份变化、保持不变的凭据及抑制条件，已核验 2026-10-15。
Linux credentials，附加组与文件系统身份，已核验 2026-10-15。
Linux setuid，特权与非特权转换及错误检查要求，已核验 2026-10-15。
Linux seteuid，允许的有效身份转换，已核验 2026-10-15。
Linux capabilities，能力限制与凭据交互，已核验 2026-10-15。
Linux 动态加载器，安全执行模式的环境限制，已核验 2026-10-15。
Linux proc_pid_status，凭据与能力状态字段，已核验 2026-10-15。

sticky bit 限制共享目录中的删除操作

Fri, 01 Oct 2027 00:00:00 +0000

Linux 目录上的 sticky bit，为删除或重命名目录项增加所有权限制。它常与宽松的目录写入、搜索权限一起使用，让多个用户能够创建临时文件，又不能任意删除彼此的条目。普通目录权限检查和 sticky 所有权检查都需要满足；sticky 是额外条件，不会替代正常访问控制，也不能只凭这一位判断整个目录里的数据是否安全。

坏掉的样子

没有 sticky 时，用户只要具备目录所需的写入与搜索权限，通常就能删除另一个用户的文件，即使文件模式完全不允许内容访问。unlink 改变的是目录里的名字与对象关系，不要求调用者能够读取或覆盖文件内容。因此，在广泛可写目录中把文件设为 000，并不能单独保护该路径不被他人删除；应分别检查父目录和文件自身的规则。

启用 sticky 后，普通用户还需要拥有该条目或包含它的目录，才能执行相关删除。具有适当 CAP_FOWNER 能力的特权进程，可以绕过这项所有权限制。因此 sticky 约束的是具体权限模型下的同级用户，并不抵御所有管理员，也不保护文件免受目录所有者删除。把它描述为绝对隔离，会夸大真实保证。

sticky 不阻止本来被允许的内容访问。一个用户可能无法 unlink 某个 0666 文件，却仍然可以读取或覆盖它。新建子目录也不会自动继承父目录的 sticky 位。混淆路径保护、内容隐私和继承，会让共享目录树表现出与顶层看起来完全不同的行为，需要沿实际数据位置检查，而不是只看根部权限字符串。

快速验证

把脚本保存为 sticky.py，在一次性 Linux 容器中以 root 运行 python3 sticky.py。控制进程需要分配三个数字身份并启动普通子进程的权限，不会创建账号。实测使用 Linux 6.12.76 和 Python 3.11.2，所有操作都发生在临时样本目录内：

from pathlib import Path
from tempfile import TemporaryDirectory
import errno,os,stat,subprocess,sys

directory_owner=61000;file_owner=61001;other_user=61002
probe_code=r'''
import os,sys
path=sys.argv[1];operation=sys.argv[2]
try:
 if operation=='unlink':os.unlink(path)
 elif operation=='rename':os.rename(path,path+'-renamed')
 elif operation=='write':
 fd=os.open(path,os.O_WRONLY|os.O_TRUNC)
 try:os.write(fd,b'other-user-write')
 finally:os.close(fd)
 elif operation=='read':
 fd=os.open(path,os.O_RDONLY);os.close(fd)
 elif operation=='mkdir':os.mkdir(path,0o777)
 else:raise AssertionError('unknown operation')
except OSError as error:print(error.errno)
else:print(0)
'''
def probe(uid,path,operation):
 result=subprocess.run([sys.executable,'-c',probe_code,str(path),operation],user=uid,group=uid,extra_groups=[],capture_output=True,text=True,timeout=5)
 assert result.returncode==0,result.stderr
 return int(result.stdout)
with TemporaryDirectory(prefix='xbcatm-sticky-') as directory:
 root=Path(directory);root.chmod(0o755);shared=root/'shared';shared.mkdir();shared.chmod(0o777)
 os.chown(shared,directory_owner,directory_owner);victim=shared/'victim'
 def make_victim(mode):
 victim.write_bytes(b'fixture');os.chown(victim,file_owner,file_owner);victim.chmod(mode)
 make_victim(0o000)
 assert probe(other_user,victim,'unlink')==0
 print('without sticky, directory write/search allows removing another owner’s mode-000 file')
 shared.chmod(0o1777);make_victim(0o666)
 assert probe(other_user,victim,'unlink')==errno.EPERM
 assert probe(other_user,victim,'rename')==errno.EPERM
 assert probe(other_user,victim,'write')==0 and victim.read_bytes()==b'other-user-write'
 victim.chmod(0o600);assert probe(other_user,victim,'read')==errno.EACCES
 print('sticky blocks outsider unlink/rename, but file permissions still govern reading and writing')
 assert probe(file_owner,victim,'unlink')==0
 make_victim(0o600);assert probe(directory_owner,victim,'unlink')==0
 print('both the entry owner and the directory owner may remove it')
 child=shared/'child';assert probe(other_user,child,'mkdir')==0
 assert not child.stat().st_mode&stat.S_ISVTX
 shared.chmod(0o1766);assert stat.filemode(shared.stat().st_mode).endswith('T')
 assert probe(other_user,shared/'blocked','mkdir')==errno.EACCES
 shared.chmod(0o1777);assert stat.filemode(shared.stat().st_mode).endswith('t')
 print('sticky is not inherited by a new subdirectory; uppercase T means other-execute is absent')

第一组使用属于一个身份的 0777 目录，以及属于另一个身份的 000 文件。第三个用户成功 unlink 该文件，证明目录写入与搜索权限可以独立于内容权限允许删除。root 只负责准备样本，真正被检查的删除动作由第三个普通身份执行，避免特权绕过使结果失去解释价值。

把目录设为 1777 后，第三个用户的 unlink 与 rename 都得到 EPERM。同一用户在文件为 0666 时，却成功覆盖内容。写入使用不含 O_CREAT 的打开方式，明确操作既有文件，避免 Linux 另一项针对共享目录普通文件的保护策略干扰结果。实验需要区分正在测量的权限规则，而不是把所有拒绝都归因于 sticky。

文件改为 0600 后，第三个用户的读取得到 EACCES。此过程中 sticky 始终启用，所以改变内容访问结果的是文件权限。两种错误来自不同检查，不能合并成“sticky 让每个临时文件私有”的结论。共享目录中的名字不容易被别人删除，与其中内容只有本人能读写，是两条需要分别成立的条件。

文件所有者随后成功删除自己的条目，重新创建的文件也能由目录所有者删除。两项操作都通过普通子进程身份检查，直接验证所有权例外，没有依赖可能具备绕过能力的 root。目录所有者对条目的管理权，与文件所有者对内容的访问权存在区别，应在共享空间设计中明确这种关系。

第三个用户接着创建子目录，后者没有自动继承 sticky。父目录改为 1766 后，权限显示以大写 T 结束，再次创建失败，因为缺少目录搜索权限。恢复 1777，则显示小写 t，表示 sticky 与其他用户执行位同时存在。大写字母不表示保护更强，而是提醒相应执行位缺失，必须结合目录遍历语义理解。

有意识地设计共享存储

当策略允许共享创建、但限制同级用户删除时，可以使用 sticky。预期读写者则需要通过文件权限或 ACL 单独配置。如果每位用户的数据必须保密，应使用另一身份实际尝试访问；只有目录带 sticky，无法证明其中的文件不可读。权限验证要针对需要保护的动作，而不是只确认配置位已经存在。

应把目录所有权理解为对目录项的管理权限。目录所有者可能无法读取某文件，却能够删除它并中断其他用户工作。在多层目录中，需要检查每个条目真正所在父目录的权限，因为受保护的祖先不会自动把 sticky 行为传给后代。顶层正确不等于整棵树已经具有相同删除边界。

创建临时文件时，应使用能够新建合适受限对象、且不信任可预测既有名字的接口。sticky 解决共享目录中一类删除问题，却不解决符号链接替换或所有不安全打开方式。应按应用实际身份与文件系统，分别验证创建、后续内容访问和清理行为，才能确认完整工作流程符合预期。

来源

inode(7)，sticky 目录、文件所有权与权限位显示，已核验 2026-09-12。
unlink(2)，目录写入搜索权限与 sticky 删除限制，已核验 2026-09-12。
capabilities(7)，CAP_FOWNER 对 sticky 目录所有权检查的例外，已核验 2026-09-12。
rename(2)，sticky 目录内重命名的权限检查，已核验 2026-09-12。