dirfd file operations (2/4)#150679
Conversation
|
This is going to need a try run for windows at least. @tgross35 I'll let you decide which jobs make the most sense here. |
|
@bors2 try jobs=x86_64-msvc-* Cc @the8472 for dirfd, and @ChrisDenton for Windows |
This comment has been minimized.
This comment has been minimized.
dirfd file operations (2/4) try-job: x86_64-msvc-*
This comment has been minimized.
This comment has been minimized.
|
I haven't had a chance to look here yet, sorry @rustbot reroll |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
@rustbot reroll |
| opts.access_mode(c::DELETE); | ||
| opts.custom_flags(c::FILE_FLAG_OPEN_REPARSE_POINT | c::FILE_FLAG_BACKUP_SEMANTICS); | ||
| let handle = self.open_file_native(from, &opts, dir)?; | ||
| // Calculate the layout of the `FILE_RENAME_INFORMATION` we pass to `NtSetInformationFile` |
There was a problem hiding this comment.
A bunch of the content here looks similar to
rust/library/std/src/sys/fs/windows.rs
Line 1313 in 2972b5e
MoveFileExW for this path at all?
There was a problem hiding this comment.
MoveFileExW operates exclusively on filenames. Dir::rename is intended to be TOCTOU-safe, so it needs to use directory Handles. I've factored out the NtSetInformationFile section of both functions into nt_rename. The implementations are a little different from one another, so I'm not 100% sure I got the function signature right. I'll wait for the CI to run and reevaluate.
This comment has been minimized.
This comment has been minimized.
| } | ||
|
|
||
| pub fn remove_file(&self, path: &Path) -> io::Result<()> { | ||
| run_path_with_cstr(path, &|path| self.remove_c(path, false)) |
There was a problem hiding this comment.
Should this check somewhere that the passed path is relative? Otherwise we're not actually getting the promised semantics: "If path is absolute, then dirfd is ignored." (https://www.man7.org/linux/man-pages/man2/unlink.2.html)
There was a problem hiding this comment.
That seems like a question for all dirfd-relative operations that take a path: should they require the path to be relative, or should they allow absolute paths and do the obvious thing for them? IMO it makes sense to allow absolute paths. That basically lets you use dirfd as a "local working directory" without the downsides of set_current_dir.
There was a problem hiding this comment.
The argument against is that people would like to use dirfd in security relevant contexts. You can build a less secure variant on top of dirfd but not really the other way around (well technically you can but defaulting to the less secure option has historically been a footgun).
But in any case, I think this is a question for libs-api.
There was a problem hiding this comment.
It's unstable, so you can put it on the open questions in the tracking issue? I don't think this needs to be settled immediately.
On linux there's openat2 which adds RESOLVE_BENEATH and RESOLVE_IN_ROOT flags which give you certain security properties, depending on which you want.
There was a problem hiding this comment.
The tracking issue explicitly says that this is NOT using O_BENEATH. We also have a fallback implementation that just stores the dir name as a string. So anything security critical seems to be already ruled out.
I have added this to #120426.
|
Reminder, once the PR becomes ready for a review, use |
|
@Qelxiros we haven't heard from you in a while here -- are you still interested in working on this? |
This comment has been minimized.
This comment has been minimized.
|
I am still interested in working on this; I had changes for the previous review in my local repo, but I forgot to push them. |
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
|
Remember to |
|
@rustbot ready |
|
@bors squash msg="add file operations to std dirfd" |
This comment has been minimized.
This comment has been minimized.
|
🔨 3 commits were squashed into b6849b3. |
18ed9ea to
b6849b3
Compare
|
@bors r+ rollup=iffy |
…acrum dirfd file operations (2/4) Previous PR: rust-lang#146341 Reference: rust-lang#139514 Tracking issue: rust-lang#120426
…uwer Rollup of 18 pull requests Successful merges: - #150679 (dirfd file operations (2/4)) - #158758 (Rename `lazy_type_alias` feature gate to `checked_type_aliases` ) - #159177 (Explicitly materialize debuginfo tests for all debuggers) - #159392 (Update Rust crate rand to v0.9.3 [SECURITY]) - #159393 (Update Rust crate rkyv to v0.8.16 [SECURITY]) - #159394 (Update Rust crate tar to v0.4.46 [SECURITY]) - #159395 (Update Rust crate tracing-subscriber [SECURITY]) - #159193 (Port compiletest's CLI to clap) - #158992 (Shorten types more when only interesting part is lifetimes) - #159226 (Track extra_lifetime_params_map per-owner) - #159273 (tidy: document u64 limit for numeric sort keys) - #159322 (Fix safety doc in intrinsics::simd) - #159329 (Fix the stale metrics directory warning) - #159357 (Add regression tests for two fixed issues) - #159360 (Remove FIXMEs referencing #44232) - #159375 (make a couple codegen-llvm tests compatible with 2021 edition) - #159381 (emit `(lldb)` prefix to make commands more distinct) - #159396 (Update actions/checkout action to v7)
View all comments
Previous PR: #146341
Reference: #139514
Tracking issue: #120426