文章

Linux 目录上的 sticky bit，为删除或重命名目录项增加所有权限制。它常与宽松的目录写入、搜索权限一起使用，让多个用户能够创建临时文件，又不能任意删除彼此的条目。普通目录权限检查和 sticky 所有权检查都需要满足；sticky 是额外条件，不会替代正常访问控制，也不能只凭这一位判断整个目录里的数据是否安全。 坏掉的样子 没有 sticky 时，用户只要具备目录所需的写入与搜索权限，通常就能删除另一个用户的文件，即使文件模式完全不允许内容访问。unlink 改变的是目录里的名字与对象关系，不要求调用者能够读取或覆盖文件内容。因此，在广泛可写目录中把文件设为 000，并不能单独保护该路径不被他人删除；应分别检查父目录和文件自身的规则。 启用 sticky 后，普通用户还需要拥有该条目或包含它的目录，才能执行相关删除。具有适当 CAP_FOWNER 能力的特权进程，可以绕过这项所有权限制。因此 sticky 约束的是具体权限模型下的同级用户，并不抵御所有管理员，也不保护文件免受目录所有者删除。把它描述为绝对隔离，会夸大真实保证。 sticky 不阻止本来被允许的内容访问。一个用户可能无法 unlink 某个 0666 文件，却仍然可以读取或覆盖它。新建子目录也不会自动继承父目录的 sticky 位。混淆路径保护、内容隐私和继承，会让共享目录树表现出与顶层看起来完全不同的行为，需要沿实际数据位置检查，而不是只看根部权限字符串。 sticky 限制目录项删除，并有所有权与能力例外。文件模式另行控制内容；实验结果是预期，不是新观察。 快速验证 把脚本保存为 sticky.py，只在获准的一次性 Linux 环境中启用断言运行 python3 sticky.py。控制进程需要 root 权限以分配三个数字身份并启动普通子进程，不会创建账号。历史文章报告 Linux 6.12.76 与 Python 3.11.2，但未找到原始日志，本轮也没有重跑。文件系统所有权、UID 映射与子进程能力必须符合预期权限模型，不能只看数字身份： ...

Cron 按日历字段匹配时间，并在匹配时启动命令。它不会天然等待同一个命令的上一次执行结束。如果每分钟触发的任务要运行七十秒，下一分钟就可能再启动一份。因此，触发规则、并发规则和成功完成状态必须分别设计，不能因为写好了一个周期表达式，就认为重复工作的所有行为都已经确定。 示意轨道展示七十秒工作结束前，下一次日历触发已到来。共享非阻塞锁使后来实例记录跳过，但不保证业务效果恰好一次。原文此前的计时结果未在本轮重跑。 把字段理解为日历选择 传统用户 crontab 一行依次包含分钟、小时、月内日期、月份、星期，然后是命令。星号表示该字段的全部取值。分钟位置的 */15 是在每个小时内选择相应分钟值，不是从上次任务结束之后再计时十五分钟。步长如果不能均匀划分字段范围，跨过边界时就可能出现不同长度的间隔，不能把它当作连续经过时长。 Debian/Vixie 格式对于两个日期字段有特殊规则：当月内日期和星期都受到限制时，满足其中一个日期条件就可能运行，而分钟、小时和月份限制仍然必须满足。这不是月份与星期之间的“或”关系。安装简短表达式之前，应列出具有代表性的实际日期核对意图，避免以为“每月某日恰好是周五”却写成两个日期条件各自都能触发。 时区、夏令时变化和停机都会影响日历调度，不同实现对跳过或重复时段的处理并不完全相同。Debian 文档为部分小幅时钟调整和固定时间任务定义了特殊行为，从其他调度器复制结论可能不适用。本实验没有修改时钟，也没有覆盖这些切换情况。日历触发同样不等于持久队列，不能自动保证停机期间错过的每次任务都会补跑。 坏掉的样子 重叠任务可能重复产生副作用、争夺资源或相互覆盖文件。如果要求同一时刻只有一个实例，就要明确实现这一政策。非阻塞建议锁可以让后来的实例记录跳过；阻塞锁则可能留下等待进程。两种选择都不自动提供业务效果恰好一次，也不能修复已经执行了一半的操作。是否允许跳过，应来自任务自己的业务要求。 本地文件锁只协调使用同一相关锁机制的参与者，不会自动串行化无关主机上的工作。网络文件系统的锁语义也需要单独确认。锁必须覆盖实际工作生命周期，跳过结果则应能被观察。如果一个实例永久卡住，后来每次触发都静默丢弃，表面上调度器还在工作，但业务可能早已停止推进，因此还要监控最近成功完成距今多久。 Cron 也并非一律没有日志。Debian 默认通过 syslog 记录任务启动，并提供更细的日志选项。命令输出可能在可用邮件链路存在时被投递，但极简容器经常没有这样的链路。应把启动、完成、失败和跳过结果写到明确目的地。启动记录只能证明任务被派发，不能证明真正的应用工作已经成功完成。 快速验证 2026-10-19 修复草案：此版本只进行了静态检查与离线命令／文件状态替身测试，没有执行 cron、crontab、账号或信号操作。技术与实际运行验证仍然受阻；下文测量值属于原始示例，不能视为修订版的执行结果。 未来执行必须另行获得授权，并使用新建的一次性 Debian 12 实验环境，预装 Python 3.11+、cron 3.0pl1-162 和 procps。环境不得挂载宿主目录，不得已有 root 任务表、cron 进程、/etc/crontab、/etc/cron.d 或其他用户任务表中启用的无关计划（包括周期目录的派发），也不得有并发管理员操作。root 只是权限前提，不能证明隔离。保存为 cron-overlap.py，未来命令为 python3 cron-overlap.py --isolated-disposable-lab。此参数仅确认由外部核实的前提，不能建立隔离。应预留约两分钟等待真实日历触发，并在结束后丢弃整个环境。 ...

重定向在命令执行前改变它的文件描述符。Shell 从左到右处理每一项，遇到打开文件或复制描述符的操作，就在那个位置完成相应变更。描述符零、一、二通常分别表示标准输入、标准输出和标准错误。把命令行读成对这些句柄的顺序操作，就能解释诊断为什么去了错误的位置，也能解释文件为什么还没有被程序读取就已经变空。 从左到右处理重定向。每次复制保留当时的目标，打开文件本身就可能在命令开始前改变数据。 打开文件本身就可能改变数据 >output 打开输出文件，并且通常把已存在的普通文件截断为零长度；>>output 使用追加方式，<input 则打开文件供读取。这些动作由 Shell 完成，不是命令所指程序的内部行为。如果必须打开的目标失败，命令不会执行，但此前已经成功的重定向仍可能创建或截断其他文件。不能把“程序没有启动”理解成“整条命令完全没有副作用”。 因此，sed expression input >input 会在转换程序读取数据之前破坏原文件。即便先写 <input 打开输入，后续重定向截断同一个底层文件，也不能保住那些内容。应写入独立临时文件，检查转换状态与结果，再根据文件归属、权限和所在文件系统，明确执行替换步骤。输入输出恰好同名时，不能指望 Shell 自动替你实现安全的原地编辑。 复制记住的是当下的目标 >log 2>&1 先让描述符一指向日志，再让描述符二引用同一个已打开目标。2>&1 >log 则先复制原来的标准输出，之后只改变描述符一，因此标准错误仍留在原目标，例如终端或负责捕获输出的管道。这里复制的是描述符引用，不是文件内容，也不是给两个数字建立一个会随之后续变化的动态连接。 Bash 的 &>log 可以简写同时重定向两条流，而 >log 2>&1 也适用于可移植 Shell。不要把它写成 >log 2>log：后者分别打开同一个文件，两份打开状态拥有独立偏移量，输出可能相互覆盖。即使描述符共享一个目标，应用程序自身的缓冲仍会影响消息真正写出的时间，所以合并日志也不自动保证业务事件严格按发生顺序排列。 ...

shell 管道把一个命令的标准输出连接到下一个命令的标准输入。各段命令可以并发运行，生产者不必全部完成后消费者才开始处理。这种连接支持增量处理，却不保证任一程序真的采用增量算法。用户态缓冲、提前结束以及各阶段的退出状态，都会影响整项操作是否达到预期。理解管道时，需要同时观察数据流、文件描述符生命周期和进程结果，不能只看最后一行输出。 管道在进程间传输字节。缓冲、所有打开端点的生命周期、每个阶段的退出结果，需要分别理解。 有限容量的字节流 管道传输的是字节，不是自带边界的记录。读者不能假设每次读取恰好得到一行，也不能假设一次读取对应生产者的一次写入。需要消息边界的程序必须自己定义和解析。标准错误默认独立于管道连接，因此，上游诊断可能显示在终端，却不会进入下游过滤器。是否合并诊断和数据应当明确决定，避免错误文本污染本来供机器读取的内容。 内核缓冲区容量有限。对于阻塞操作，管道满时写者等待；管道空但仍有写端打开时，读者等待。这种反压限制生产者在这个管道上领先消费者的距离。容量取决于操作系统和配置，并不是普遍固定为六十四千字节。程序自身仍可能维护不断增长的数据结构，因此，使用管道不等于整个处理链的内存已经有界，必须另外检查各段算法。 用户态缓冲还可能引入额外等待。某个程序向终端逐行刷新，改成管道输出后却可能先积累较大的块。此时消费者看起来没有动静，并不代表内核丢了数据；数据可能尚未离开生产者的用户态缓冲。应先检查程序提供的流式处理和刷新控制，再考虑调整内核限制。完整排序等转换本身也需要先看到更多输入，添加随意的睡眠无法改变这种依赖。 原子写入与缓冲容量是不同属性。Linux 对不超过 PIPE_BUF 的适当写入提供不与其他写者交错的保证，并有阻塞模式条件；这仍然不会为读者建立消息边界。几次短写入可能被一次读取取得，一次写入也可能分几次才读完，不能把某次观察到的块大小当作解析协议。 坏掉的样子 只有所有指向写端的文件描述符都关闭，并且缓冲中的剩余字节已经读完，读者才会看到文件结束。关闭写端不会丢弃已经进入管道的数据。如果某个子进程继承了不再使用的写端，即使看起来生产者已经退出，消费者也可能一直等不到结束。反方向上，所有读端关闭后继续写入会产生 SIGPIPE；忽略这个信号时，写操作会以 EPIPE 错误失败。因此，消费者主动提前结束，也可能让原本正常的生产者以非零状态退出。 Bash 默认返回最后一段命令的状态。上游失败、下游 cat 成功读完部分数据时，整体可能仍然成功。开启 pipefail 后，整体返回从左到右最靠右的非零状态，并不是时间上最先失败的进程，也不是最左侧失败命令。PIPESTATUS 数组短暂保留每段结果，应立即保存，因为后面一次赋值或打印就可能替换这份观察记录。 Bash 管道中的阶段通常运行在子 shell 环境。在管道右侧循环里给变量赋值，通常不会修改调用者的变量。lastpipe 选项在关闭作业控制时可以改变最后一段的执行位置，因此依赖状态保留的代码必须明确 shell 配置。需要保留循环状态时，也可以让循环直接通过重定向读取输入，避免把它放进管道带来的作用域变化。 ...

交互式作业控制让 shell 管理共享控制终端的多个进程组。终端同一时刻只有一个前台组，其他作业可以在后台运行，也可以保持停止状态。前台归属、是否运行和 shell 的作业表，是三种不同状态。后台作业不等于已经暂停，停止作业也不等于已经终止；判断当前交互为什么没有进展，需要先分清这些状态。 是否运行与终端前台归属是不同状态。bg 恢复作业但不交出键盘，fg 恢复前台交互。shell 作业表不等于持久服务状态。 坏掉的样子 启用终端信号处理时，输入已配置的中断或暂停字符，会由终端驱动向前台组发送信号，不是只发送给最后打印文字的那个进程。控制字符重新映射、终端模式变化以及应用信号处理函数，都可能改变结果。因此只说按某个键，并不能保证在每个程序和每套终端配置中得到相同反应，还要核对实际处理条件。 普通后台作业尝试读取自己的控制终端时，会被 SIGTTIN 停止。把它放到后台，并不会给它单独分配一份键盘输入流。输出又有不同规则：后台写入通常允许，还会受 TOSTOP 等终端设置影响。因此后台执行不意味着彻底脱离终端，输入、输出和前台信号各有自己的约束，需要分别观察。 %1 这类作业标识属于某个 shell 的作业表，不是全局进程编号。换一个终端或进入非交互 shell 后，不能假定相同号码仍然管理相同任务。管道和后台命令如何分组，也取决于真实 shell 调用是否启用了作业控制。交互终端中看见的行为，不能不加检查地套到所有脚本启动路径上。 快速验证 把脚本保存为 jobcontrol.py，在装有 Bash 和 Python 的 Linux 环境中运行 python3 jobcontrol.py。保留的 2026-10-15 审查曾使用 Linux 6.18.44、Bash 5.2.37 和 Python 3.12.14 原样重跑两种语言样本。这些是历史观察，本次源码审查没有重新运行交互实验。脚本创建自己的伪终端与交互 Bash，不会把控制字符发给你用于启动它的终端： ...

共享临时目录是其他用户也可能写入的命名空间，并不意味着里面每个文件都公开可读；内容访问仍受文件权限约束。真正危险的假设，是以为选定一个路径，就已经拥有这个名字对应的对象。应原子地创建新对象，并继续使用返回的句柄，而不是信任一个可预测名字，或先检查它不存在、稍后再打开。 名字归属与内容访问是两回事 Linux 的 /tmp 常用模式 1777，即宽松的目录写入、搜索权限，加上 sticky 位。sticky 限制其他用户删除或重命名目录项，却不让现有文件自动保密，也不提前保留尚未创建的名字。文件属主、目录属主、能力及其他访问控制仍然重要。应检查实际环境，不能假定所有操作系统都采用同一路径、挂载方式和权限。 普通写入打开可能跟随预先存在的符号链接。O_CREAT|O_EXCL 拒绝已经存在的最后一个路径名称，包括符号链接。O_NOFOLLOW 则拒绝最后一段是符号链接的情况，但单独使用时不会拒绝既有普通文件，也不保护所有祖先目录。这些是不同契约。应使用可信父目录和适当的临时文件接口，不能把一个标志当成通用路径安全方案。 创建模式也只在真正新建文件时生效。以 O_CREAT 和模式 0600 打开已有文件，不会收紧它原先的权限。随机名字降低碰撞概率，但安全性质来自排他创建，而不只是字符串看起来难以猜测。只生成名字的接口仍留下一段空隙，其他进程可以在真正创建之前占用该名字，因此先检查再创建也不能消除竞争窗口。 位置设置不等于隔离 Python 的 tempfile.mkstemp 安全地创建并打开文件，调用方负责关闭和删除。TemporaryDirectory 提供受限目录和正常退出时的清理。TMPDIR 影响位置选择，却不会自己创建私有目录，也不验证隔离策略。Python 会缓存默认目录选择；如果操作必须使用某个位置，应明确传入 dir=，不要依赖运行中修改环境变量来重新选择。 systemd 的 PrivateTmp= 可以给服务单独的临时文件命名空间，但它改变共享行为，并有平台与 unit 条件，不等同于设置一个环境变量。服务分别使用独立命名空间时，不能依赖跨服务的 /tmp 路径通信。下方本地实验不会启用或验证 systemd 隔离，也不能据此宣称部署已经具有相同隔离边界。 tmpfs 随使用量分配空间，在可用且被允许时可以使用交换空间。没有指定大小时，默认容量上限是物理内存的一半；这是上限，不是挂载时预留的内存。数据分配额度和 inode 数量都可能分别阻止后续工作。/tmp 也不一定挂在 tmpfs 上，因此容量监控应依据实际挂载与负载，不能把目录名字直接当成存储类型。 ...

环境是程序启动时收到的一组名称与字符串值。子进程通常接收父进程选定的环境，修改自己的副本不会回写父进程或兄弟进程。这是一条有用的配置边界，却不是命令没有副作用的保证：程序仍可能根据配置修改共享文件、数据库或其他资源。理解变量如何传递，与判断程序实际会做什么，是两个需要分别核对的问题。 沿直接启动者传入的值检查。环境副本不会回写；但子 Shell、新执行的 Bash 程序与当前 Shell 中的点命令，保留和修改的状态并不相同。 导出决定另一个程序能收到什么 Shell 变量与环境条目有关联，但并不是同一概念。DEMO_SETTING=local 创建或更新 Shell 参数，export DEMO_SETTING 才把它标记为启动外部命令时应包含的环境项。父 Shell 能打印变量，不代表新启动的 Bash 就能看到未导出的值。把赋值写进某个配置文件，也不会让每个 Shell 自动读取它；还必须确认文件是否在对应启动路径上被加载。 Bash 从环境继承的变量已经带有导出属性，之后重新赋值会保留该属性。因此子进程修改值后，再启动孙进程时可以直接传递新值，不要求每一代重复写一次导出命令。unset 删除变量，Bash 的 export -n 则取消导出属性但保留当前 Shell 中的值。真正需要确认的是直接启动者传入了什么，而不是机械地搜索祖先脚本里出现了多少次导出语句。 ...

进程组是内核维护的一组进程，通过进程组编号 PGID 标识，可用于向一个作业投递信号等操作。父子关系与组成员关系是两个维度：有亲缘关系的进程可以属于不同组，组长也不必始终存活，其他成员仍可继续属于原组。理解这些关系，才能判断一个控制动作到底覆盖哪些进程，以及某个进程退出意味着什么。 零号信号可以在不投递信号的情况下检查存在性与权限，但不是存活或完成确认。僵尸进程仍可能存在，检查之后目标状态也可能变化。因此，应保留本例通过等待回收确认完成的步骤，不能用一次成功的权限探测替代退出结果，更不能据此判断业务工作已经安全结束。 成员关系选择接收者，各进程的处理方式决定响应。组可以在组长退出后继续存在，发送成功不是完成证据。 坏掉的样子 向单个进程发信号，不会自动向它的所有子进程发信号。向进程组发信号，选择的是当前组成员，也不是整棵后代树。创建新会话或新组的子进程，可能已经位于目标范围之外；反过来，多个兄弟进程可以刻意共享一个组，即使任何一个都不是另一个的父进程。进程树图不能直接替代组成员清单。 组投递也不保证所有接收者作出相同响应。一个成员可能采用默认动作，另一个安装处理函数，还有成员可能忽略或阻塞允许处理的信号。因此，组操作不会自动形成原子停止，也不能证明组内全部工作完成。每个进程的信号处理方式和应用关停协议仍然决定最终结果，需要分别观察投递、响应与退出。 组长退出不等于整个组退出。只要还有成员，PGID 就可能继续有效，即使组长已经被父进程回收。只观察组长状态的监督程序，可能在成员仍运行时报告结束。组身份应与实际生命周期管理结合，不能被当作一批启动工作永久不变的标识，也不能单凭领导进程消失就推断所有资源都已释放。 快速验证 把脚本保存为 groups.py，在具有 Python 3.11 或更新版本的一次性 Linux 环境中运行 python3 groups.py。2026-10-15 的复核记录了该样本在 Linux 6.18.44/Python 3.12.14 上通过，此次未重跑。启动时 TERM 须采用默认处理方式，TERM 与 USR1 均须未被阻塞。只向已核对的新建子进程组发信号，绝不能使用继承或共享的进程组： ...