每日推歌已发送

🔑 write() 成功了，为什么文件还是可能丢？

很多人第一次写文件时都会有一个直觉：write() 已经返回成功，数据就应该已经“进硬盘”了。这个直觉是错的。write() 在大多数 Unix/Linux 系统里，通常只表示“内核已经收下这段数据”，而不是“存储设备已经真的写好”。内核之所以这样设计，不是偷懒，而是为了性能：如果每次写入都强行等硬盘落盘，程序会慢得像卡住一样。于是操作系统把数据先放进 page cache，等合适的时候再批量刷盘，这样吞吐量高得多。

这就带来一个非常重要的后果：程序看起来“保存成功”了，机器一断电，文件仍然可能丢，甚至可能只写进去一半。尤其是你在更新配置文件、日志文件、状态文件时，这个坑非常常见。很多人以为“我都 close 了，应该安全了吧”，也不完全对。close() 主要是释放文件描述符，刷盘可能仍然是延后的。真正要逼内核把修改推到稳定存储，通常要显式调用 fsync() 或 fdatasync()。

这也是为什么很多可靠软件不直接覆盖原文件，而是采用“先写临时文件，再 fsync，再 rename”的套路。因为 rename 在同一文件系统内通常是原子的：要么旧文件还在，要么新文件完整替换上去，不容易出现“文件存在，但内容只剩半截”这种恶心状态。不过这里还有第二层坑：你只 fsync 了文件本身，还不一定够。如果你新建了文件或者依赖目录项变化，目录也可能需要 fsync，否则断电后名字映射未必稳定。设计上这是把“数据内容”和“目录元数据”分开处理，目的是避免每次小改动都付出巨大的同步成本。

所以，write() 保证的是“本次系统调用把字节交给了内核”，不是“崩溃后这些字节仍然活着”。这套设计很实用，因为大部分写操作根本不值得每次都同步到底层设备；但一旦你在做配置保存、钱包、索引、状态机快照、提交记录这类关键数据，就不能再装作 page cache 和断电不存在。

🧪 课后一题：一个程序先用 write() 写完 config.json，然后立刻退出，没有调用 fsync()。如果这时机器突然断电，config.json 的新内容一定已经安全保存了吗？答案：不一定。write() 成功通常只表示数据进入了内核缓冲区，未必已经真正落盘。

💡 易混淆点：write() 成功、close() 成功、文件“看起来能读出来”这三件事，都不等于“断电后数据仍然存在”。

#CS

📸 @shiryudo202488
第68回伊勢市民大会
in神宮会館2026.8.2


https://youtube.com/channel/UCR7JYSKxqXUfQrbrHWDdOyA?si=Do3H64GGTHaDas7f

第68届伊势市民大会
在金谷殿2026.8.2


https://youtube.com/channel/UCR7JYSKxqXUfQrbrHWDdOyA?si=Do3H64GGTHaDas7f #剣道 #活人剣 #志龍道
原文 #剣道

🔐 JWT 算法混淆（Algorithm Confusion）不是“密钥泄露”，而是验证器把不同算法当成一回事

JWT 看起来只是三段 Base64 文本，真正危险的地方不在“能不能看懂 payload”，而在服务端怎么验签。算法混淆的经典问题是：开发者本来想用 RS256 这种“私钥签名、公钥验证”的非对称方案，结果验证库却信了 token 头里的 alg，被攻击者改成 HS256。这样一来，服务端原本公开给大家的 RSA 公钥，反而会被当成 HMAC 的“对称密钥”来验签。攻击者拿得到公钥，就能自己伪造一个“合法”管理员 token。

这事为什么会发生？因为很多人把“算法类型”和“密钥类型”分开想了。库如果写得松，流程就会变成“先读 token 头，看它说自己是什么算法，再拿你给我的 key 去试着验”。这就是烂设计：把安全决策交给了攻击者可控的输入。好一点的实现应该反过来，服务端先固定这个接口只接受 RS256，再用 RSA 公钥按 RS256 去验；token 头里的 alg 只能拿来做一致性检查，不能拿来决定验证路径。

现实里的防法也很直接。第一，不要接受客户端声明算法，服务端把允许的算法白名单写死。第二，别把“一个 key 对象”同时喂给多种算法路径，更不要让 RSA 公钥有机会落到 HMAC 验证器里。第三，拒绝 alg=none，也拒绝算法和 key 类型不匹配的情况。第四，升级 JWT 库，很多老漏洞本质上是库默认行为太宽松。最后，鉴权不能只看“签名过了”，还要继续校验 iss、aud、exp 和用途，不然你只是把另一种伪造票据放进系统。

🧪 你在审一个登录网关，发现代码写的是“从 JWT 头读取 alg，然后把配置里的 public_key.pem 传给通用 verify() 函数”。现在系统号称使用 RS256。攻击者最可能怎么打？
把 token 头里的 alg 改成 HS256，再用公开的 RSA 公钥当 HMAC 密钥重新签一个管理员 token。如果验证库允许算法混淆，服务端就会把公钥错当成对称密钥，结果验签通过。

💡 核心记忆：JWT 的算法选择权绝不能交给 token 头，服务端必须先定算法，再验签。

#Security

📚 「に伴って」不等于所有“随着”：它强调“前项变化，后项也跟着发生”

很多人写技术日语时，会把“随着……，……”一律写成「〜につれて」或「〜とともに」。这就容易出错。比如想说“随着系统规模扩大，运维成本也上升”，这里如果你想突出的是一种客观、连带性的变化，用「に伴って」更稳。它常见于技术说明、研究报告、制度变化、系统升级这类偏正式场景，语气比「につれて」更书面，也更像在描述“一个变化带来另一个变化”。

但它不是万能替换。先说边界：「に伴って」前面通常接“变化、扩张、增加、改定、移行、進展”这类会引发连带结果的事，后面多半也是客观结果，不太适合接个人意志、命令、请求。比如「サービス拡大に伴って、監視項目を見直してください」就别扭，因为后半句是请求动作，不是自然发生的结果。这里改成「サービス拡大に伴い、監視項目を見直す必要がある」才像正式书面语。

它和相近表达也得分清。「につれて」更偏“逐渐变化的过程”，常用于观察到的同步变化；「とともに」范围更宽，可以表示“同时”“一起”“随着”，但有时只是并列，不一定强调因果连带；「に伴って」则更像“由于前项的进展/变化，后项也相应发生”。写论文、技术报告、变更说明时，这个差别很值钱。

例句直接套：
クラウド環境への移行に伴って、従来の境界型防御だけでは対応が難しくなった。
随着迁移到云环境，仅靠传统的边界型防御已经很难应对了。

利用者数の増加に伴い、認証基盤のスケーラビリティが課題となっている。
随着用户数量增加，认证基础设施的可扩展性正在成为课题。

法規制の改定に伴って、研究データの管理手順も見直された。
随着法规修订，研究数据的管理流程也被重新审视了。

💡 記憶ポイント：前面放“会带来变化的事件”，后面放“随之出现的客观结果”时，用「に伴って／に伴い」。如果后半句是命令、请求、个人打算，通常别硬用。想写“逐渐随着……变化”，优先考虑「につれて」；想写“同时/连同一起”，再看是不是「とともに」。

#日本語