cap-std
cap-std copied to clipboard
Capability-oriented version of the Rust standard library
cap-std and cap-async-std will need a semver bump in order to pick up the fix for #270, which is needed in order to compile with changes to nightly Rust. ~~I'm...
Not sure when Nightly introduced a change that broke the compilation of `cap-primtives` here, I'm on latest from today `cargo 1.64.0-nightly (85b500cca 2022-07-24)`. latest stable (1.62) and beta (1.63.0-beta.7) works...
std has recently sealed its `FileTypeExt` traits, so cap-primitives can no longer implement them for its own types. Fortunately, these traits are just used as extension traits, so we can...
The `kf_path` field of `libc::kinfo_file` holds the path.
This function is a higher-level abstraction that doesn't really fit in rustix, and complicates an upcoming rustix refactoring, so move it out to cap-std.
As @kubkon observed, `NtOpenFile` provides a more efficient and likely more reliable way to implement `openat`-like behavior on Windows. As an example, Rust is now using it this way in...
Rust 1.56 stablizes [`std::os::unix::fs::chroot`](std::os::unix::fs::chroot). Should cap-std add a `chroot` function that can be called on a `Dir`? It'd be implemented in terms of `fchroot` on platforms that have that, or...
On Windows, files on network shares have a canonical path which starts with the UNC "\\?\" prefix. With these prefixes, the OS no longer handles "." paths and trailing slashes,...
FreeBSD 13.0 added a `O_RESOLVE_BENEATH` flag to [`open`](https://www.freebsd.org/cgi/man.cgi?query=open&sektion=2&format=html#end) which appears to implement similar behavior to Linux's `openat2`'s `RESOLVE_BENEATH` flag, which should allow us to implement sandboxed `open` with a single...
According to [this blog post](https://blog.malwarebytes.com/mac/2021/08/macos-11s-hidden-security-improvements/#O_NOFOLLOW_ANY), macos 11 has a new `O_NOFOLLOW_ANY` flag that causes `open` to fail if any path component is a symlink. Assuming symlinks are relatively rare, cap-std...