Aleksa Sarai
Aleksa Sarai
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)...
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...