libpathrs
libpathrs copied to clipboard
openSUSE
C-friendly API to make path resolution safer on Linux.
One of the problems exposed by research into #7 is that there are a **lot** of issues with safe `/proc` usage on older kernels (and many more kernel features are...
Right now it's not possible to `readlink` an `O_PATH | O_NOFOLLOW` handle to a symlink. While this isn't strictly required for security (after all, `readlinkat` will give you an error...
We need to have a pidfd-based interface to grab the equivalent of `/proc/self/exe`. Because it's possible to bind-mount over magic-links we can't trust `/proc/self/exe` and thus need a proc-less way...
We need to have an alternative interface to re-open through `/proc/self/fd/$n`. Because it's possible to bind-mount over magic-links we can't trust `/proc/self/fd/$n` and thus need a proc-less way to do...
This is something we really need to provide to avoid the attacks we are defending against in #7.
Right now we rely on manually updating `include/pathrs.h` each time we modify the C API. It would be a *much* better idea to auto-generate it. Unfortunately we can't do this...
Right now we don't have any kind of real versioning in the C API. It would be nice to have symbol versioning ([this post has some interesting advice](https://plan99.net/~mike/writing-shared-libraries.html)), and probably...
We should generate some kind of pkg-config for `libpathrs` (this will be useful for the Go bindings since Go supports pkg-config much more naturally than manually dealing with include parts)....
While adding `RESOLVE_NO_XDEV` support to the `openat2(2)` backend is incredibly trivial (add the `RESOLVE_NO_XDEV` flag), for the emulated backend it appears to be an open problem to detect a mount-point...
We need to have a Go-like `os.RemoveAll` implementation, since a lot of Go programs depend on this behaviour. In principle users could implement this manually but it's really suboptimal if...