3 ms·

But those are all unsafe, taking raw strings. Why can I easily use "*at" functions from Python's stdlib, but not Rust's? They are much safer against path trav

by nh2 5mo ago

But those are all unsafe, taking raw strings. Why can I easily use "*at" functions from Python's stdlib, but not Rust's? They are much safer against path traversal and symlink attacks. Working safely with files should not require *const c_char. This should be fixed .

kibwen 5mo ago
> But those are all unsafe, taking raw strings. The parent was asking for access to the C syscall, and C syscalls are unsafe, including in C. You can wrap that syscall in a safe interface if you like, and many have. And to reiterate, I'm all for supporting this pattern in Rust's stdlib itself. But openat itself is a questionable API (I have not yet seen anyone mention that openat2 exists), and if Rust wanted to provide this, it would want to design something distinct. > Why can I easily use "*at" functions from Python's stdlib, but not Rust's? I'm not sure you can. The supported pattern appears to involve passing the optional `opener` parameter to `os.open`, but while the example of this shown in the official documentation works on Linux, I just tried it on Windows and it throws a PermissionError exception because AFAIK you can't open directories on Windows.
- masklinn 5mo ago
  > AFAIK you can't open directories on Windows. You can but you have to go through the lower level API: NtCreateFile can open a directory, and you can pass in a RootDirectory handle to following calls to make them handle-relative.
  - ChrisSD 5mo ago
    You can open directories using high level win32 APIs. What you need NtCreateFile for is opening files relative to an open directory.
- rendaw 5mo ago
  I took parent's message to be asking why the standard library fs primitives don't use `at` functions under the hood, not that they wanted the `at` functions directly exposed. > which Rust's stdlib chose not to expose i.e. expose through things like `File::open()`.
  - kibwen 5mo ago
    > why the standard library fs primitives don't use `at` functions under the hood In this case it wouldn't seem to make sense to use `at` functions to back the standard file opening interface that Rust presents, because it requires different parameters, so a different API would need to be designed. Someone above mentioned that such an API is being considered for inclusion in libstd in this issue: https://github.com/rust-lang/rust/issues/120426 https://github.com/rust-lang/rust/issues/120426
yx827ha 5mo ago
The nix crate provides the safe wrappers. https://docs.rs/nix/latest/nix/fcntl/fn.openat2.html https://docs.rs/nix/latest/nix/fcntl/fn.openat2.html

by nh2 5mo ago

kibwen 5mo ago

> But those are all unsafe, taking raw strings. The parent was asking for access to the C syscall, and C syscalls are unsafe, including in C. You can wrap that syscall in a safe interface if you like, and many have. And to reiterate, I'm all for supporting this pattern in Rust's stdlib itself. But openat itself is a questionable API (I have not yet seen anyone mention that openat2 exists), and if Rust wanted to provide this, it would want to design something distinct. > Why can I easily use "*at" functions from Python's stdlib, but not Rust's? I'm not sure you can. The supported pattern appears to involve passing the optional `opener` parameter to `os.open`, but while the example of this shown in the official documentation works on Linux, I just tried it on Windows and it throws a PermissionError exception because AFAIK you can't open directories on Windows.

masklinn 5mo ago
> AFAIK you can't open directories on Windows. You can but you have to go through the lower level API: NtCreateFile can open a directory, and you can pass in a RootDirectory handle to following calls to make them handle-relative.
- ChrisSD 5mo ago
  You can open directories using high level win32 APIs. What you need NtCreateFile for is opening files relative to an open directory.
rendaw 5mo ago
I took parent's message to be asking why the standard library fs primitives don't use `at` functions under the hood, not that they wanted the `at` functions directly exposed. > which Rust's stdlib chose not to expose i.e. expose through things like `File::open()`.
- kibwen 5mo ago
  > why the standard library fs primitives don't use `at` functions under the hood In this case it wouldn't seem to make sense to use `at` functions to back the standard file opening interface that Rust presents, because it requires different parameters, so a different API would need to be designed. Someone above mentioned that such an API is being considered for inclusion in libstd in this issue: https://github.com/rust-lang/rust/issues/120426 https://github.com/rust-lang/rust/issues/120426

yx827ha 5mo ago

The nix crate provides the safe wrappers. https://docs.rs/nix/latest/nix/fcntl/fn.openat2.html https://docs.rs/nix/latest/nix/fcntl/fn.openat2.html