Feature request: export some bits of FdExt

[nikstur]

In NixOS, we need to canonicalize symlinks all the time before we transition from the initrd to userspace. We currently chroot and then call realpath. It would be awesome if we could use this library instead.

Is something like root.realpath (similar to root.readlink) feasible or is it inherently insecure?

[cyphar]

It depends on what you plan to use it for and also a little on what you want a full path for. The general case for this would be effectively https://github.com/cyphar/filepath-securejoin and these kinds of APIs are unsafe in general.

If you plan to use the path with some other tool to actually operate on the path, then it cannot be safe. If you need a string to reference a file the only real alternative is name_to_handle_at(2)-style file handles (for filesystems which support them) and those are not really supported by most external tools anyway.

If it is an existing inode and you just need the logical path (at some point in time!) to match with some other information then you can use Root::resolve and then look at /proc/self/fd/$n (there is an internal trait we use for this that is not exported called as_unsafe_path, maybe it should be exported as an extension trait for everything that implements AsFd?). You just need to be aware that this path is only valid for some instant at time and is not a guarantee the file is still there -- you should never use these paths for actual VFS operations.

For the case of a non-existent file, I was originally opposed to the idea completely because hallucinating path components (which is necessary if parent path components don't exist either) leads to really unfortunate behaviour -- especially with dangling symlinks. However, runc had to re-add this feature (see opencontainers/runc@3f92552 and opencontainers/runc#4985) because some the previous "hallucinated" dangling-symlink handling was depended on by users, so I do empathise with the wish to have this be a thing you can do with libpathrs. But I would still prefer to push users away from building new tools that have this feature, because hallucinating the path to only then re-do the lookup is incredibly wasteful and bug-prone.

[cyphar]

After speaking about this in person, I reckon that exposing as_unchecked_path and reopen from FdExt would probably be a good idea. I don't think we should have this for the C API (since you can do it manually fairly easily) but the trait stuff is quite useful for Rust.

[cyphar]

Ah I realised this kinda overlaps with #262 (at least for the re-open bit). I guess it's cleanest to have these be separate traits...