remove usage of absolute rpaths#12754
Closed
thestinger wants to merge 1 commit intorust-lang:masterfrom
thestinger:rpath
Closed
remove usage of absolute rpaths#12754thestinger wants to merge 1 commit intorust-lang:masterfrom thestinger:rpath
thestinger wants to merge 1 commit intorust-lang:masterfrom
thestinger:rpath
Conversation
Contributor
Author
|
This is the uncontroversial part of the change. I haven't removed the fallback or relative rpaths. |
Contributor
|
To be clear, this doesn't remove all absolute rpaths, but only the absolute rpath to the target crate. This leaves the fallback absolute rpath to sysroot - removing that would cause all crates that are moved on disk to break. |
This is a significant security issue as it adds a hidden library path based on the location of the build directory. It is *always* wrong in an installed package, and can be leveraged by an unprivileged user to inject libraries into a binary called by another user or even root. Closes #11746 This is a step towards fixing #11747 but is only a partial solution.
Contributor
|
The error is possibly with multi-host cross-compiles. I think there's an option in the makefile to set LD_LIBRARY_PATH when --disable-rpath; that may just need to be always on now. |
Contributor
Member
|
This may be able to get by with removing this logic: https://github.com/mozilla/rust/blob/master/mk/main.mk#L345-L355 (removing the condition on |
Member
|
Closing due to inactivity. |
alexcrichton
added a commit
to alexcrichton/rust
that referenced
this pull request
Apr 8, 2014
Concerns have been raised about using absolute rpaths in rust-lang#11746, and this is the first step towards not relying on rpaths at all. The only current use case for an absolute rpath is when a non-installed rust builds an executable that then moves from is built location. The relative rpath back to libstd and absolute rpath to the installation directory still remain (CFG_PREFIX). Closes rust-lang#11746 Rebasing of rust-lang#12754
alexcrichton
added a commit
to alexcrichton/rust
that referenced
this pull request
Apr 10, 2014
Concerns have been raised about using absolute rpaths in rust-lang#11746, and this is the first step towards not relying on rpaths at all. The only current use case for an absolute rpath is when a non-installed rust builds an executable that then moves from is built location. The relative rpath back to libstd and absolute rpath to the installation directory still remain (CFG_PREFIX). Closes rust-lang#11746 Rebasing of rust-lang#12754
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jul 25, 2022
fix: Fix VSCode status bar tooltip not showing the error messages
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
This is a significant security issue as it adds a hidden library path
based on the location of the build directory. It is always wrong in an
installed package, and can be leveraged by an unprivileged user to
inject libraries into a binary called by another user or even root.
Closes #11746
This is a step towards fixing #11747 but is only a partial solution.