-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Correctly convert an NT path to a Win32 path in read_link
#107978
Conversation
Hey! It looks like you've submitted a new PR for the library teams! If this PR contains changes to any Examples of
|
Would it make sense to only add the prefix in those cases? Then simple paths like |
To be clear the absolute path returned from the OS API is like We could maybe transform the NT prefix into the non-verbatim win32 equivalent while taking care also to avoid doing so if the transformation might be lossy. But this is more difficult because there are a lot of things to be aware of (like if the filename happens to match DOS device name). Hm, I guess the easiest thing would be to attempt to pass the modified path via |
0b3fff1
to
178f7bb
Compare
I have stumbled upon this bug recently, which causes some real issues. When a link is made with a UNC target, the read_link implement returns a buggy path. For example, a This can cause issues as this path can actually exist, so the read_link call can point to a completely different file, which I think can be a source for security issues. Also, it makes it impossible for the caller to find out if the path is towards a network server, or whether it is absolute or relative. I was pondering creating an issue for this, but I found this MR which would solve the issue. Is there anything blocking it? |
@bors r+ |
Correctly convert an NT path to a Win32 path in `read_link` This can be done by simply changing the `\??\` prefix to `\\?\`. Currently it strips off the prefix which could lead to the wrong path being returned (e.g. if it's not a drive path or if the path contains trailing spaces, etc). r? libs
This can be done by simply changing the `\??\` prefix to `\\?\` and then attempting to convert to a user path. Currently it simply strips off the prefix which could lead to the wrong path being returned (e.g. if it's not a drive path or if the path contains trailing spaces, etc).
Oh, the function this is using changed in another PR. Rebasing... |
@bors r=m-ou-se |
📌 Commit 6d0a0836f654f2ffedbbbb0caff34bd17e898b04 has been approved by It is now in the queue for this repository. |
This comment has been minimized.
This comment has been minimized.
Rollup of 11 pull requests Successful merges: - rust-lang#107978 (Correctly convert an NT path to a Win32 path in `read_link`) - rust-lang#110436 (Support loading version information from xz tarballs) - rust-lang#110791 (Implement negative bounds for internal testing purposes) - rust-lang#110874 (Adjust obligation cause code for `find_and_report_unsatisfied_index_impl`) - rust-lang#110908 (resolve: One more attempt to simplify `module_children`) - rust-lang#110943 (interpret: fail more gracefully on uninit unsized locals) - rust-lang#111062 (Don't bail out early when checking invalid `repr` attr) - rust-lang#111069 (remove pointless `FIXME` in `bootstrap::download`) - rust-lang#111086 (Remove `MemEncoder`) - rust-lang#111097 (Avoid ICEing miri on layout query cycles) - rust-lang#111112 (Add some triagebot notifications for nnethercote.) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Correctly convert an NT path to a Win32 path in `read_link` This can be done by simply changing the `\??\` prefix to `\\?\`. Currently it strips off the prefix which could lead to the wrong path being returned (e.g. if it's not a drive path or if the path contains trailing spaces, etc). r? libs
Correctly convert an NT path to a Win32 path in `read_link` This can be done by simply changing the `\??\` prefix to `\\?\`. Currently it strips off the prefix which could lead to the wrong path being returned (e.g. if it's not a drive path or if the path contains trailing spaces, etc). r? libs
This can be done by simply changing the
\??\
prefix to\\?\
.Currently it strips off the prefix which could lead to the wrong path being returned (e.g. if it's not a drive path or if the path contains trailing spaces, etc).
r? libs