文件 · XB 现场笔记

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。

文件描述符标识进程持有的打开引用

Sun, 21 Feb 2027 00:00:00 +0000

文件描述符是一个进程内部用于引用已打开资源的小整数。进程的描述符表把这个数字映射到内核维护的打开文件描述；对于普通文件，打开描述包含当前偏移和文件状态标志。另一个进程可以把相同整数用于完全不同的资源，因此数字本身不是全局文件身份。理解描述符表、打开描述与底层文件之间的关系，才能正确判断复制、关闭和继承的效果。

坏掉的样子

dup 分配另一个描述符，让它引用同一份打开文件描述；它不是简单复制整数，也不是重新按路径打开文件。因此，两份描述符读取普通文件时共享偏移。相反，再次打开相同路径，通常会得到具有独立偏移的新打开描述。设备与 inode 身份相同，不代表打开状态也相同，排查读取位置异常时必须区分这两个层面。

状态标志和描述符标志也属于不同层次。通过 F_SETFL 改变共享打开描述的状态，复制出来的引用都会看到；close-on-exec 标志则分别属于每个描述符。把这些层次混在一起，可能改变另一个消费者的行为，也可能让描述符意外进入后续执行的程序。选择复制引用之前，需要知道自己想独立控制的是寿命、偏移，还是继承行为。

关闭描述符会释放表项，整数可能立即被再次使用。只保留旧数字的代码，之后可能操作新资源，而不是稳定得到“无效描述符”错误。当描述符在回调、线程或库之间传递时，需要明确所有权和寿命，不能仅检查一个整数非负，就认定它仍然代表原来那个对象。数字看起来没有变化，引用关系却可能已经完全不同。

快速验证

在一次性 Linux 环境中运行下面的 Python 脚本。它创建两份无害临时文件，并关闭自己打开的所有描述符。实测环境为 Linux 6.12.76、Python 3.11.2。实验没有后台线程，因此可以观察分配与复用，不会有另一个线程同时抢占刚释放的编号：

from pathlib import Path
from tempfile import TemporaryDirectory
import fcntl,os

with TemporaryDirectory(prefix='xbcatm-fds-') as directory:
 root=Path(directory);original=root/'original';other=root/'other'
 original.write_bytes(b'abcdef');other.write_bytes(b'replacement')
 handles=set()
 try:
 first=os.open(original,os.O_RDONLY);handles.add(first)
 duplicate=os.dup(first);handles.add(duplicate)
 independent=os.open(original,os.O_RDONLY);handles.add(independent)
 assert first!=duplicate
 assert os.read(first,2)==b'ab' and os.read(duplicate,2)==b'cd'
 assert os.read(independent,2)==b'ab'
 assert os.lseek(first,0,os.SEEK_CUR)==4
 print('dup uses a different descriptor but shares offset; a separate open has its own offset')
 flags=fcntl.fcntl(duplicate,fcntl.F_GETFL)
 fcntl.fcntl(duplicate,fcntl.F_SETFL,flags|os.O_NONBLOCK)
 assert fcntl.fcntl(first,fcntl.F_GETFL)&os.O_NONBLOCK
 assert not fcntl.fcntl(independent,fcntl.F_GETFL)&os.O_NONBLOCK
 os.set_inheritable(first,False);os.set_inheritable(duplicate,True)
 assert not os.get_inheritable(first) and os.get_inheritable(duplicate)
 print('file status flags shared by dup; close-on-exec flags remain descriptor-specific')
 os.close(first);handles.remove(first)
 reused=os.open(other,os.O_RDONLY);handles.add(reused)
 assert reused==first and os.read(first,32)==b'replacement'
 assert os.read(duplicate,2)==b'ef'
 print('closed descriptor number is reused for another file; surviving duplicate still reads original')
 original.unlink();os.lseek(duplicate,0,os.SEEK_SET)
 assert os.fstat(duplicate).st_nlink==0 and os.read(duplicate,32)==b'abcdef'
 print('unlink removes the pathname while an open descriptor retains access')
 finally:
 for handle in handles:os.close(handle)

第一次打开读取 ab，复制描述符接着读取 cd，两者此时都看到偏移四。对同一个文件独立执行 open，则仍从自己的起始位置读到 ab。这些精确字节证明哪份状态被共享；仅仅看到两个入口都能读取相同内容，并不足以区分复制引用和独立打开，因为它们本来就可以指向同一个底层文件。

脚本通过复制描述符设置 O_NONBLOCK，从原描述符读到该标志，而独立打开仍保留此前状态。这里使用普通文件，验证的是标志归属，不是声称普通磁盘读取会因此变成异步操作。随后给复制描述符设置不同的可继承属性，确认原描述符的 close-on-exec 行为没有改变，从而把两类标志的共享范围实际区分开。

关闭第一份描述符后，再打开另一文件会复用相同整数。通过保存旧编号的变量读取，此时得到的是 replacement；仍存活的复制描述符却继续读到原文件末尾的 ef。这直接说明，一个已经关闭的整数并不是对原对象的持久引用，甚至不能指望误用时总是马上报错。重新分配之后，它可能成为完全合法但对象错误的句柄。

取消原路径的链接会删除目录项。复制描述符的文件状态报告链接数为零，但重新定位并读取，仍能得到 abcdef。样本中的其他打开引用，也在关闭前继续有效。删除名字、关闭某个描述符和释放最后一份打开引用，是不同操作，因此不能根据某个路径消失，就推断文件内容已经没有任何使用者。

脚本用集合记录当前真正拥有的描述符，在编号复用前先移除已经关闭的条目，避免把同一个复用整数当成两份需要分别关闭的资源。真实程序在转移所有权，或用包装对象管理底层描述符时，也需要这种清晰关系。否则一个迟到的清理动作，就可能关闭另一个模块刚刚打开的新对象。

在交接处定义所有权

函数应说明自己只是借用描述符，还是接管关闭责任。适合时使用具有明确寿命的包装对象，避免两个独立所有者都去关闭同一个整数。复制引用可以分离描述符本身的寿命，但仍然共享打开描述状态；如果需要独立偏移，就应明确采用符合需求的独立打开，而不是把 dup 当成完整状态复制。

启动另一个程序时，应显式选择继承。语言运行时可能默认创建不可继承描述符，子进程接口也可能关闭允许集合以外的全部句柄。应验证真实启动行为，不能假定 fork、exec 和高级进程接口会暴露完全相同的描述符。继承规则既影响功能，也影响哪个进程仍然持有资源。

最后，操作要匹配资源类型。管道和套接字同样通过描述符访问，但不会因此具有普通文件的可定位偏移契约。正确管理描述符，需要同时考虑资源语义、打开描述状态，以及哪个组件可以关闭每一份进程内句柄，而不是把所有整数都当成可以互换操作的文件编号。

来源

open(2)，进程描述符表、打开文件描述、偏移与标志，已核验 2026-09-12。
dup(2)，新描述符分配、共享打开描述与描述符标志，已核验 2026-09-12。
unlink(2)，删除名字后通过打开引用保留文件，已核验 2026-09-12。