On Tue, Apr 02, 2024 at 02:00:52AM -0700, Gordon Messmer wrote: > On 2024-03-30 09:12, Neal Gompa wrote: > > Note that dlopen() doesn't fix the problem of the giant libsystemd in > > the first place. It just obfuscates the true dependency graph of > > libsystemd. > > > This isn't my area of expertise, but I am curious: > > Why doesn't dlopen() solve the problem? As best I understand it, liblzma > was able to steal one (or more) of the symbols from libcrypto.so.3 because > it ran constructors at a point in time when the GOT was still writable. > After loading shared objects is complete, that table is made read-only. If > dlopen() is used after the program starts, then even if the library is > loaded, it can't steal symbols in the table any more. > > Or do I misunderstand this entirely?
You understood correctly ;) As you wrote, dlopen() is done after RELRO has taken effect. Also, dlopen() is only called lazily when the required library is to be used for the first time… So in this particular case, the program could call sd_notify(), but no dlopen() call would be done. Zbyszek -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
