libpathrs
libpathrs copied to clipboard
openSUSE
C-friendly API to make path resolution safer on Linux.
JFYI: After the [re-occuring security problems with travis](https://arstechnica.com/information-technology/2022/06/credentials-for-thousands-of-open-source-projects-free-for-the-taking-again/) we disabled this CI provider for the openSUSE org. Not sure if this project is still alive.
Have you seen https://crates.io/crates/openat ? I use it in rpm-ostree, curious whether you considered using it instead of rolling custom wrappers here.
Messing around with `cffi` is far too much of a pain (and also requires me to try to figure out `setuptools`). But pyo3 allows us to write Rust-native Python modules...
Right now, we do a few security checks when operating on `/proc`, namely: * That `/proc` has an `fs_type` of `PROC_SUPER_MAGIC` (which can't be faked by FUSE), to make sure...
Would be great if we could safely open another dirfd descending from an existing one, or other O_PATH-style opens for `AT_EMPTY_PATH`-style usages.
This is basically a reboot of the `snafu` porting effort. I will need to consider this for a bit longer, but I like that `error-chain` has a much more opaque-to-the-user...
The current method of configuration is a really bad idea (exposing structure internals of `Root` is going to cause problems, I can feel it in my bones). So we should...
The current `pathrs_configure` is designed after Linux's extensible syscall semantics. However, it seems to me that a string-based configuration setup would be far easier to extend naturally. Maybe the value...
For hyper-concerned users we could implement a backend that actually uses `pivot_root` and then does the path resolution like that. It would be a bit ugly (and possibly somewhat slow)...