-
Notifications
You must be signed in to change notification settings - Fork 12.6k
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
Tracking Issue for directory handles #120426
Comments
During the ACP a survey of platform support was requested to make sure that fallbacks won't be needed on Tier-1 platforms. libc/syscall surveyFor restricted conversion between Presence of Tier 1Windows
Linux
macos
Tier 2freebsd, illumos, netbsd, solaris
fuchsia
ios
wasm-emscripten
wasm-wasi
redox
The redox syscall crate lists no *at calls at all? uefiListed as no_std in the platform support documentation. Somehow has some pieces in std anyway. No Not checked
|
Regarding redox, relibc is the right place to look for support. We should be able to support the same list of functions as Linux and the BSDs. |
The ACP mentions “it may be possible to add the Dir methods directly to ReadDir instead”. This is problematic because |
From a Miri perspective I'd love to see this, it would let us implement support for emulation of
I am somewhat surprised to see this TODO item. In other areas Rust chose to not provide lower-quality fallback implementations, e.g. famously Rust atomics are always hardware atomics and never lock emulated. I can't find discussion of this point in the ACP either. What is the reasoning here for preferring an insecure emulation over a security guarantee stated in the API? |
Operating on a directory is a fairly basic operation, like opening a
Additionally, the platforms where That said, maybe we can add a Also, this wouldn't be a runtime fallback but a platform-based fallback. All tier-1 platforms will use real handles and fail if they're not available. E.g. if something blocks |
Can this be completed with a compiler warning for these platforms? Since this will be something included in the target type, I would imagine so. |
@rustbot ping fuchsia Since it appears that functions being available in the libc crate is not a reliable indicatior that they actually work, is there a better overview of the available posix APIs? I'm interested in the file descriptor APIs listed in #120426 (comment) |
Hey friends of Fuchsia! This issue could use some guidance on how this should be |
@the8472 how odd, we do support it at the Fuchsia layer, maybe we're not exposing it through fdio. We'll do some investigation and report back. |
@the8472 got confirmation from our team that we do support |
Feature gate:
#![feature(dirfd)]
This is a tracking issue for directory handles. Such handles provide a stable reference to an underlying filesystem object (typically directories) that are less vulnerable to TOCTOU attacks and similar races. These security properties will be platform-dependent. Platforms that don't provide the necessary primitives will fall back to operations on absolute paths.
Additionally they may also provide performance benefits by avoiding repeated path lookups when performing many operations on a directory.
Sandboxing is a non-goal. If a platform supports upwards path traversal via
..
or symlinks then directory handles will not prevent that. ProvidingO_BENEATH
-style traversal is left to 3rd-party crates or future extensions.Public API
Steps / History
openat
emulation based onPath
sgetdents
to get free conversion between dirfds andReadDir
*at
callsUnresolved Questions
Footnotes
https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩
The text was updated successfully, but these errors were encountered: