fix(windows): refuse .part reparse points - #113
Merged
Conversation
…ctions Closes the Windows half that 0.7.2/0.7.3 explicitly deferred. safe_create_part (Windows): opens with FILE_FLAG_OPEN_REPARSE_POINT + FILE_FLAG_BACKUP_SEMANTICS (allows opening dir junctions), then uses GetFileInformationByHandle (handle-based, no TOCTOU) to reject reparse points. safe_resume_part / safe_open_part (Windows): same approach — FILE_FLAG_OPEN_REPARSE_POINT + FILE_FLAG_BACKUP_SEMANTICS, then GetFileInformationByHandle to reject reparse points and non-regular files. Added windows-sys 0.59 with Win32_Storage_FileSystem + Win32_Foundation. Three #[cfg(windows)] tests: use for junction creation (no privilege needed). Tests accept either outcome (open-fails OR attr- rejects) since dir junctions may need FILE_FLAG_BACKUP_SEMANTICS to open for write. Runtime verification needs a Windows runner (#34). cargo check --target x86_64-pc-windows-gnu --tests: clean.
The 3 win_safe_*_refuses_junction tests + create_junction helper were at ~main.rs:4755, which is inside the main code (not inside #[cfg(test)]). They compiled as dead code into the normal binary and the test harness never collected them, so they'd never actually run even on a Windows runner. Moved them into the existing #[cfg(test)] mod tests block where the Unix transfer_part_refuses_symlink / transfer_open_part_refuses_symlink tests already live. Now the harness collects them on Windows and the 'never used' warnings disappear. cargo check --target x86_64-pc-windows-gnu --tests: warning-clean for these functions (verified in the shared checkout before moving to worktree).
This was referenced Aug 4, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Harden Windows
.partwrites against symlinks and junctions. The helpers open withFILE_FLAG_OPEN_REPARSE_POINTandFILE_FLAG_BACKUP_SEMANTICS, then inspect the opened handle withGetFileInformationByHandlebefore allowing writes.The
windows-sys = 0.59feature list includesWin32_Storage_FileSystem,Win32_Foundation, andWin32_Security.Win32_Securityis retained for the named-pipeSECURITY_ATTRIBUTESwork in PR #63; the lists must be merged, not replaced.Tests
The Windows tests include a junction smoke check and file-symlink redirect refusal for resume/open. The meaningful tests assert
PermissionDenied, thereparse pointrefusal message, and unchanged outside-target contents.The throwaway no-hardening control in PR #111 ran on Windows and produced the predicted result: the two symlink tests failed because unhardened OpenOptions returned
Okfor the outside target, while the junctionCREATE_NEWsmoke test passed withEEXIST. This demonstrates that the two symlink assertions are load-bearing.Scope
Source reading establishes that main's Windows helpers lacked a reparse check while the Unix helpers checked the opened file. The control run now also demonstrates the vulnerable before-state. PR #113's exact head
a71098df0dfb8ef3e7b72da1789b0be3e5c7bb42is green on all 11 checks.