build: Restore backwards compatibility with existing containers #904
Conversation
This file contains 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
|
Build failed.
|
|
recheck |
|
Build succeeded.
|
The path of the dynamic linker (ie., PT_INTERP), as specified in an
architecture's ABI, often starts with /lib or /lib64, not /usr/lib or
/usr/lib64. eg., it's /lib/ld-linux-aarch64.so.1 for aarch64 and
/lib64/ld-linux-x86-64.so.2 for x86_64.
Unfortunately, until very recently [1], only the host's /usr was
present inside a toolbox container's /run/host, not /lib or /lib64.
Therefore, simply prepending /run/host to the /usr/bin/toolbox
binary's existing PT_INTERP entry wouldn't locate the host's dynamic
linker inside the toolbox container. This broke backwards compatibility
with every container out there, except the ones created with the
current development version in Git.
To restore backwards compatibility, the /lib and /lib64 symbolic links
must be resolved to their respective locations inside /usr.
The following caveats must be noted:
* With glibc, even the basename of the path of the dynamic linker as
specified in an architecture's ABI, is a symbolic link to a file
named ld-<glibc-version>.so. However, this file can't be used as
the PT_INTERP entry, because its name will change when glibc is
updated and the PT_INTERP entry will become invalid until the
/usr/bin/toolbox binary is rebuilt.
* On Debian, a path like /lib64/ld-linux-x86-64.so.2 doesn't resolve
to something inside /usr/lib64. Instead it ends up inside
/usr/lib/x86_64-linux-gnu through a series of symbolic links:
- /lib64 -> usr/lib64
- /usr/lib64/ld-linux-x86-64.so.2
-> /lib/x86_64-linux-gnu/ld-2.28.so
- /lib -> usr/lib
* It's assumed that a symbolic link with the basename specified in
the ABI lives in the same directory as the actual dynamic linker
binary named ld-<glibc-version>.so.
Fallout from 6063eb2
[1] Commit d03a5fe
containers#827
containers#821
debarshiray
force-pushed
the
wip/rishi/dynamic-linker-canonicalize-path
branch
from
5429d5e to
112f281
Compare
|
Build succeeded.
|
|
We urgently need more people to test this one out, so let's get this in. |
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.
The path of the dynamic linker (ie., PT_INTERP), as specified in an
architecture's ABI, often starts with
/libor/lib64, not/usr/libor/usr/lib64. eg., it's/lib/ld-linux-aarch64.so.1for aarch64 and/lib64/ld-linux-x86-64.so.2for x86_64.Unfortunately, until very recently [1], only the host's
/usrwaspresent inside a toolbox container's
/run/host, not/libor/lib64.Therefore, simply prepending
/run/hostto the/usr/bin/toolboxbinary's existing PT_INTERP entry wouldn't locate the host's dynamic
linker inside the toolbox container. This broke backwards compatibility
with every container out there, except the ones created with the
current development version in Git.
To restore backwards compatibility, the
/liband/lib64symbolic linksmust be resolved to their respective locations inside
/usr.The following caveats must be noted:
With glibc, even the basename of the path of the dynamic linker as
specified in an architecture's ABI, is a symbolic link to a file
named
ld-<glibc-version>.so. However, this file can't be used asthe PT_INTERP entry, because its name will change when glibc is
updated and the PT_INTERP entry will become invalid until the
/usr/bin/toolboxbinary is rebuilt.On Debian, a path like
/lib64/ld-linux-x86-64.so.2doesn't resolveto something inside
/usr/lib64. Instead it ends up inside/usr/lib/x86_64-linux-gnuthrough a series of symbolic links:/lib64->usr/lib64/usr/lib64/ld-linux-x86-64.so.2->
/lib/x86_64-linux-gnu/ld-2.28.so/lib->usr/libIt's assumed that a symbolic link with the basename specified in
the ABI lives in the same directory as the actual dynamic linker
binary named
ld-<glibc-version>.so.Fallout from 6063eb2
[1] Commit d03a5fe
#827
#821