-
Notifications
You must be signed in to change notification settings - Fork 441
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
elf: resolve paths in ldd()
to purge relative path components
#2932
Conversation
Still debugging this error. For some reason there appears to be an empty string lib getting returned in the crystal case, which expands to the cwd by abspath. |
ldd may return paths with relative components such as "..", e.g.: { 'linux-vdso.so.1': '', 'libc.so.6': '/snap/core/current/lib/x86_64-linux-gnu/libc.so.6', 'libnvidia-container.so.1': '/root/prime/usr/bin/../lib/x86_64-linux-gnu/libnvidia-container.so.1', 'libcap.so.2': '/snap/core/current/lib/x86_64-linux-gnu/libcap.so.2', 'libdl.so.2': '/snap/core/current/lib/x86_64-linux-gnu/libdl.so.2', 'libseccomp.so.2': '/snap/core/current/lib/x86_64-linux-gnu/libseccomp.so.2' } (1) Resolve the paths before using them to ensure we have a consistent values that do not look odd in potential warnings/errors (e.g. corrupted ELF). This also appears to expose an issue with the FakeElf fixture which was not creating a fake "barsnap.so.2" in the core base path. This updates the fixture to create one in the same manner as it does for the root libraries. (2) In the same example above, we can see linux-vdso has an empty string. In Ubuntu 16.04, ldd will return a slightly different formatted string which results in an empty path for the "found" shared object path. I do not believe it has caused a problem before attempting to use abspath on it. Check for the empty-string case and ignore it. We don't need to check linux-vdso, and calling abspath on it will resolve to the current working directory. (3) Add some unit tests for validating ldd parsing. Signed-off-by: Chris Patterson <chris.patterson@canonical.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems to be a rogue change.
Also, can you please do successive commits instead of amends to make it easier to review? Spotting the change is a task on itself.
Will do, sorry about that. I hadn't thought you reviewed it yet. |
I just did not assess, but I have been looking at this since it first came out :-) |
Signed-off-by: Chris Patterson <chris.patterson@canonical.com>
Signed-off-by: Chris Patterson <chris.patterson@canonical.com>
elf: resolve paths in
ldd()
to purge relative path componentsldd may return paths with relative components such as "..", e.g.:
{
'linux-vdso.so.1': '',
'libc.so.6': '/snap/core/current/lib/x86_64-linux-gnu/libc.so.6',
'libnvidia-container.so.1': '/root/prime/usr/bin/../lib/x86_64-linux-gnu/libnvidia-container.so.1',
'libcap.so.2': '/snap/core/current/lib/x86_64-linux-gnu/libcap.so.2',
'libdl.so.2': '/snap/core/current/lib/x86_64-linux-gnu/libdl.so.2',
'libseccomp.so.2': '/snap/core/current/lib/x86_64-linux-gnu/libseccomp.so.2'
}
(1) Resolve the paths before using them to ensure we have a consistent
values that do not look odd in potential warnings/errors (e.g.
corrupted ELF).
This also appears to expose an issue with the FakeElf fixture which
was not creating a fake "barsnap.so.2" in the core base path. This
updates the fixture to create one in the same manner as it does for
the root libraries.
(2) In the same example above, we can see linux-vdso has an empty string.
In Ubuntu 16.04, ldd will return a slightly different formatted string
which results in an empty path for the "found" shared object path. I do
not believe it has caused a problem before attempting to use abspath
on it.
Check for the empty-string case and ignore it. We don't need to check
linux-vdso, and calling abspath on it will resolve to the current
working directory.
Signed-off-by: Chris Patterson chris.patterson@canonical.com