irisandClaude Opus 5
d0b6b66a44
`OpenOptions::mode` applies to a file the call creates and to nothing else, so rewriting a file that already existed kept whatever permissions it had. Three functions above, `create_dir` has carried a comment about exactly this hazard since it was written -- the file path never got the same treatment. This is not hypothetical here. `certs.rs` reissues the TLS leaf and rewrites its **private key on every start**, so a key that ever existed world-readable would have stayed that way for the rest of its life, with every subsequent start looking like it was setting the mode. The config's temp file is the other one: normally fresh, but a leftover from a crashed save would be reused with its old mode and then renamed over the real config, which holds the enrolled token hashes. Set through the open handle rather than the path, deliberately: `set_permissions` on a path re-resolves it, so between the open and the chmod something could put a different file -- or a symlink to one -- where this was, and the mode would land there instead. A handle cannot be redirected. Three tests, and the first was checked against the bug rather than only against the fix: with the new line commented out it fails with "rewriting left it at 644". Found by dev-updater's session, which had taken this module for a shared crate and read it as a unit. I had spotted the same line being wrong in their new `append_file` and missed that `create_file` -- the one I wrote -- had it too. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017xn8nHw1tw1R6PtiY1eEtw