Cabal-HEAD/ghc-HEAD injects insecure RUNPATHs to a temp build directory in dynamic binaries using library of the same package #4025
Comments
|
That definitely looks bad. If the regression is recent, it's likely to be related to #3979. Also adding @christiaanb |
|
@trofi What does the combination of GHC-HEAD/Cabal-1.24-git-branch give you? |
|
Attn. @bgamari - we probably don't want to ship GHC 8.0.2 with this bug. |
|
@23Skidoo @bgamari I don't think this bug exists in GHC 8.0.2. That is, given: and, I get: That is, on the |
|
@christiaanb Have you been able to reproduce the issue with Cabal HEAD? |
|
@23Skidoo Yes I can reproduce using ghc-HEAD and Cabal-HEAD, using: and Which is a cabal-install based on the Cabal and cabal-install sources of 266c5aa I get: |
|
The problem is most likely somewhere in https://github.com/haskell/cabal/blob/master/Cabal/Distribution/Simple/LocalBuildInfo.hs#L234, which for the |
|
First off, a clarifying note: it is NOT an error for Next, I think @christiaanb is right and it has nothing to do with dynlibdir changes; there's a decent shot that 0d15ede tickled an existing bug in Here's my theory:
If this is correct, then 8.0.2 shouldn't have this bug. Would be a good thing to check when we cut the RC. I guess the fix is, we should vary the "inplace" registrations based on whether or not we are building for inplace or not. |
|
I am quite a bit annoyed by this bug, because it is caused by the inplace package database. With a per-component build, the problem goes away, because you're always building w.r.t. the library-dirs from the externally provided package database, which has the correct path. No fix needed. But given that we can't get rid of the inplace db (yet), we must find some suitable solution. If we really do believe the inplace database will go away soon, I suppose we could just bash our way to a solution: for example, we could add some completely alternate codepath for computing rpaths of internal libraries (there'd need to be a way of filtering out the bad inplace internal entries from installedPkgs), which would just not get exercised if you did a per-component build. We shouldn't just revert 0d15ede because that would regress #2971 (well, I guess didn't actually affect anyone, so maybe we could...) This bug raises a concern: if GHC ever builds any of the file paths from the inplace package db into the object files it generates, then GHC builds are nondeterministic. (It doesn't seem to do so at the moment, but it is a bit worrisome); a bug of this nature would be analogous to this one. |
23Skidoo
changed the title
In 1.24, installedPkgs contained only references to the external package database, not any internal libraries. In particular, when we built a dynamically linked executable, installedPkgs did NOT have a reference to the internal library; instead, depLibraryPaths has a special case (hasInternalDeps) to add the final libdir to the RPATH. In HEAD, after 0d15ede, we started adding internal libraries (with the INPLACE registrations) to installedPkgs to fix haskell#2971. But depLibraryPaths was not updated, which means that the inplace registrations got picked up and added to the RPATH, resulting in bad temporary directories showing up in RPATHs. In this commit, we just filter out internal entries from installedPkgs and compute the library dirs for them from scratch (this code already existed, so no loss!) Fixes haskell#4025. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
In 1.24, installedPkgs contained only references to the external package database, not any internal libraries. In particular, when we built a dynamically linked executable, installedPkgs did NOT have a reference to the internal library; instead, depLibraryPaths has a special case (hasInternalDeps) to add the final libdir to the RPATH. In HEAD, after 0d15ede, we started adding internal libraries (with the INPLACE registrations) to installedPkgs to fix haskell#2971. But depLibraryPaths was not updated, which means that the inplace registrations got picked up and added to the RPATH, resulting in bad temporary directories showing up in RPATHs. In this commit, we just filter out internal entries from installedPkgs and compute the library dirs for them from scratch (this code already existed, so no loss!) Fixes haskell#4025. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
In 1.24, installedPkgs contained only references to the external package database, not any internal libraries. In particular, when we built a dynamically linked executable, installedPkgs did NOT have a reference to the internal library; instead, depLibraryPaths has a special case (hasInternalDeps) to add the final libdir to the RPATH. In HEAD, after 0d15ede, we started adding internal libraries (with the INPLACE registrations) to installedPkgs to fix haskell#2971. But depLibraryPaths was not updated, which means that the inplace registrations got picked up and added to the RPATH, resulting in bad temporary directories showing up in RPATHs. In this commit, we just filter out internal entries from installedPkgs and compute the library dirs for them from scratch (this code already existed, so no loss!) Fixes haskell#4025. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Let's look at small-ish systemwide-installed idiii package. I'm installing it the same way on 2 systems as:
Good system (ghc-8.0.1/Cabal-1.24):
Bad system (ghc-8.1.20161022/Cabal-HEAD):
Note additional RUNPATH to a temp build directory. Gentoo package manager flags that entry as insecure:
I use
/dev/shm/as a temp directory in that system.Adding @ezyang and @dcoutts for visibility.
The text was updated successfully, but these errors were encountered: