New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
current_exe() returns invalid path on linux when exe has been deleted #69343
Comments
Since So it probably needs a doc update. In the case of mount namespaces this might also be subject to confusion attacks, so this value generally shouldn't be given too much trust. |
Rather than simply checking for IMHO. This doesn't explicitly go against the docs on |
Isn't it Linux only? |
While current_exe() might return all kinds of different paths caused by symlinks or mounts it should return something that points to the executable even if you might not have the permissions to access it. But |
Does |
Yes and yes. |
Then another option is to simply return the symlink itself instead of the target. At least as a fallback. After all it may be the only existing reference to an inode, e.g. in the mem_fd case |
That won't work if you pass the result of |
If that symlink was the last reference to the inode then it will never work. So if it's just a fallback you don't lose anything. |
Returning the symlink itself would be a bad idea, even if
|
You would pass But yes, all of these are workarounds with their own limitations. The proper solution is, at least on linux, to pass around file descriptors which are valid for their whole existence. |
As i mentioned in the other thread, it may be worth just deprecating this API in favour of another crate which offers multiple options with different guarantees. |
Calling
current_exe()
on linux after the original executable has been deleted or replaced results in an invalid path being returned.Output
Ok("/path/to/executable (deleted)")
Desired behavior
While it is the correct behavior of the underlying
/proc/self/exe
to append the string(deleted)
to the original pathname the result is not a valid path and might even end up pointing to a completely different file.I would either expect the docs to explicitly mention this behavior or classify it as an error and return
io::ErrorKind::NotFound
accordingly.Meta
rustc --version --verbose
:I would gladly claim this issue if you agree to it.
The text was updated successfully, but these errors were encountered: