fix(si): support self update through symbolic links on macOS #2689
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When the launcher (i.e. the `si` program) is installed from a non-root user and when they don't have either `$HOME/.local/bin` or `$HOME/bin` currently in their `$PATH`, the launcher is installed to `$HOME/.si/bin/si` and a symlink is created at `/usr/local/bin/si` with a sudo call (that is, the root user owns the symlink as it is a system directory). Prior to this change, when a self update was attempted (via calling `si update --self) under the scenario above, the new binary would attempt to write itself to a temp file under the *symlink*'s parent directory of `/usr/local/bin`. This would cause an permissions error that looks like: ``` Downloading new binary Replacing '/usr/local/bin/si' with new binary Error: 0: io: Permission denied (os error 13) at path "/usr/local/bin/.si.__temp__6DqCUt" 1: Permission denied (os error 13) at path "/usr/local/bin/.si.__temp__6DqCUt" Location: <unknown> Backtrace omitted. Run with RUST_BACKTRACE=1 environment variable to display it. Run with RUST_BACKTRACE=full to include source snippets. ``` Additionally, if the non-root user happened to have write permission on `/usr/local/bin`, then the new binary would overwrite the symlink and install itself to `/usr/local/bin/si`, thus eliminating the symlink. The detection of a symlink and its resolution by calling `std::fs::read_link` is provided via a fix in the upstream [self-replace](https://crates.io/crates/self-replace) crate. References: mitsuhiko/self-replace#18 Signed-off-by: Fletcher Nichol <fletcher@systeminit.com>
|
I made sure to test this out on macOS by building the binary and getting the path to it with |
|
bors merge |
|
Build succeeded: |
|
I'll add that for anyone affected by this issue, you'll want to re-run the shell download script with: curl -sSfL https://auth.systeminit.com/install.sh | shOr re-downloading a new release from the download page. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When the launcher (i.e. the
siprogram) is installed from a non-root user and when they don't have either$HOME/.local/binor$HOME/bincurrently in their$PATH, the launcher is installed to$HOME/.si/bin/siand a symlink is created at/usr/local/bin/siwith a sudo call (that is, the root user owns the symlink as it is a system directory).Prior to this change, when a self update was attempted (via calling
si update --self) under the scenario above, the new binary would attempt to write itself to a temp file under the *symlink*'s parent directory of/usr/local/bin`. This would cause an permissions error that looks like:Additionally, if the non-root user happened to have write permission on
/usr/local/bin, then the new binary would overwrite the symlink and install itself to/usr/local/bin/si, thus eliminating the symlink.The detection of a symlink and its resolution by calling
std::fs::read_linkis provided via a fix in the upstream self-replace crate.References: mitsuhiko/self-replace#18