-
Notifications
You must be signed in to change notification settings - Fork 35
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
NSS is a problem #129
Comments
TestsBuild on Debian 10, run on CentOS 6Running
strace:
We can see:
It's a wonder this worked. Build on CentOS 6, run on Debian 10First of all, the application didn't run correctly: It failed to resolve gid/uid numbers:
And this snippet of strace output:
...shows similar behavior, but with the versions reversed. |
Possible Workarounds
|
https://sourceware.org/glibc/wiki/FAQ
It might be worth asking how popular There is even a very recent golang PR, authored by the alpine linux creator, for an accepted proposal to prefer |
So, you could potentially avoid doing a lot of work (and making staticx binaries better IMO, you can look at that glibc strace in the linked page and see how gross it is) by vendoring the appropriate functions from musl libc and patching the resulting executable. But I don't know how important or popular |
The Running
Command:
Output:
Note that my |
@joshuarli Thanks for the insight! staticx will never be able to fully support NSS, and indeed that is not my goal. My goal with this issue is to simply avoid the issues that are caused by the
This is one road that I could take, but:
It's present on every Linux system I've ever used. Whether or not users realize it or not, installed packages sometimes modify
Note:
|
Looking towards getting this functionality into CompatibilityThere are several realms between which there needs to be compatibility:
The goal of StaticX is to completely isolate D, so we can ignore that. I think C != B is an unsupported use-case of staticx: It's the same as moving a dynamically-linked program to another system which is the problem that staticx intends to solve. So for this conversation we'll assume B == C. That leaves us with A and C. The compatibility requirements between A and C is historically non-existent: The bootloader is statically-linked against musl libc. But now,
|
Why did this job fail?
Okay, this comes from a super-weird corner case test (that isn't really realistic):
The statically-linked dynamic applications obviously should work fine. And the glibc dynamic app should be using the same libc as the python interpreter, and its dependencies will get picked up okay. The weird (and arguably invalid) one here is Regardless, the error occurs (I think) because the staticx bootloader sets So even though this is a weird test case, it highlights the fact that |
I was able to successfully hook However, this presents a decision: Do we always want to unset
So maybe it doesn't really even matter. To me, it seems that the safest choice is to unset Edit: Crap. I forgot that the PyInstaller bootloader will fork and exec, just like staticx bootloader. So this means that we will (under the current plan) So I guess this means we need to do the On the plus side, PyInstaller execs itself (which is already patched), so we don't need to worry about |
Bringing along your own extra dynamically-linked executable is not supported by staticx. Even the name of this overall test says "static". See: #129 (comment)
Bringing along your own extra dynamically-linked executable is not supported by staticx. Even the name of this overall test says "static". See: #129 (comment)
Bringing along your own extra dynamically-linked executable is not supported by staticx. Even the name of this overall test says "static". See: #129 (comment)
Bringing along your own extra dynamically-linked executable is not supported by staticx. Even the name of this overall test says "static". See: #129 (comment)
Bringing along your own extra dynamically-linked executable is not supported by staticx. Even the name of this overall test says "static". See: #129 (comment)
Bringing along your own extra dynamically-linked executable is not supported by staticx. Even the name of this overall test says "static". See: #129 (comment)
Bringing along your own extra dynamically-linked executable is not supported by staticx. Even the name of this overall test says "static". See: #129 (comment)
Bringing along your own extra dynamically-linked executable is not supported by staticx. Even the name of this overall test says "static". See: #129 (comment)
Bringing along your own extra dynamically-linked executable is not supported by staticx. Even the name of this overall test says "static". See: #129 (comment)
Bringing along your own extra dynamically-linked executable is not supported by staticx. Even the name of this overall test says "static". See: #129 (comment)
Bringing along your own extra dynamically-linked executable is not supported by staticx. Even the name of this overall test says "static". See: #129 (comment)
Bringing along your own extra dynamically-linked executable is not supported by staticx. Even the name of this overall test says "static". See: #129 (comment)
To close the loop on the previous dialog, I ended up (in #139), dropping the |
Background
Name Service Switch (NSS) is a feature of GLIBC that allows different name databases to be extensible and dynamically enabled via
/etc/nsswitch.conf
. ASERVICE
will be provided bylibnss_SERVICE.so
.Core Problem
When a glibc binary built with staticx runs on a target system:
/etc/nsswitch.conf
on the target system and try to load variouslibnss_SERVICE.so
librarieslibnss_SERVICE.so
(assuming it exists) from the target system will be (attempted to be) loaded which is likely not compatible with the bundled glibcIssues
libnss_SERVICE.so
libraries are not discoverable byldd
libnss_SERVICE.so
files, the target system could still have additional services configured which are not bundled.libnss_SERVICE.so
file (and their dependencies), there's no way to know if they would be compatible with the target system.libnss_winbind.so
talks towinbindd
References
/tmp/staticx-CamJai/.staticx.prog: relocation error: /lib/x86_64-linux-gnu/libnss_dns.so.2: symbol __res_maybe_init version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference
-l /lib/x86_64-linux-gnu/libnss_dns.so.2 -l /lib/x86_64-linux-gnu/libresolv.so.2
Terms
The text was updated successfully, but these errors were encountered: