Aleksa Sarai
Aleksa Sarai
This is primarily an issue with the Go bindings (which don't expose `(*procfs.Handle).open`) but not being able to really `switch` effectively on `ProcfsBase` is kinda unergonomic as a user, as...
Our argument order is the opposite to `ln(1)` and `symlink(2)`/`link(2)` which is just going to cause confusion. We will need `@LIBPATHRS_0.3` (or `@LIBPATHRS_0.2.1`) symbol versions for this...
I suspect some users would want to be able to get `reopen` for any `AsFd`. We also probably want to return `OwnedFd`...
The `InodeType` thing is quite ugly, we should just create methods for each file type.
This would be very useful for us, as it would allow us to work around the kinds of issues we had with `/proc/thread-self` when joining PID namespaces -- if you...
At the moment, procfs automatically assumes `task_active_pid_ns(current)` when you create a new filesystem, but it would be really handy for container runtimes to be able to specify the PID namespace...
`ProcfsBase::ProcPid` (#205) is inherently racy because of pid recycling, which pidfds are intended to solve. However, it isn't necessarily obvious to me how we should handle using pidfds. I guess...
`open(O_CREAT)` without O_NOFOLLOW allows you to create the target of a dangling symlink. I suspect this is a very rarely-used feature of `O_CREAT` (and I view it as a mis-feature)...
At the moment, `Root::create_file` is explcitly `O_CREAT|O_EXCL|O_NOFOLLOW` which is the most secure and straight-forward implemementation that will work regardless of the resolver implementation. However, it seems possible users might prefer...
Initially the plan was for `libpathrs` to only support Linux but given that `umoci` supports non-Linux operating systems, it might make sense to have an `O_PATH` resolver that works on...