Hi Micah, Thanks so much. Prepending the install path PREFIX in the dlopen call works a dream!
Trying the absolute path first is necessary to avoid macOS (with hardened runtime) printing that warning message every time the command is run. If that call fails, it reverts back to the original code which also allows tests to succeed. I can share a patch if you like, but it would be of limited use as I've just hard-coded the path seeing as my knowledge of Makefiles is limited and I don't know how to reference the PREFIX configure option from within others.c ! Many thanks again for your help. Mark > On 24 Feb 2021, at 2:25 am, Micah Snyder (micasnyd) <micas...@cisco.com> > wrote: > > The license stuff is tricky. I'm not a lawyer, so my advice is maybe not too > helpful here. We include the UnRAR license with ClamAV, but I suppose could > be more specific to say that UnRAR's restrictions on reverse engineering to > create a RAR archiver apply to ClamAV if UnRAR is linked with ClamAV. That's > how I would want to go about it, anyways. I guess maybe I need to ask a > lawyer. > > The function that loads libclamurnar_iface is load_module() and is invoked > here: > https://github.com/Cisco-Talos/clamav-devel/blob/dev/0.104/libclamav/others.c#L314 > > As you can see, there are two variants. The first uses libtool's LTDL to load > it, the second (newer variant) doesn't. I added the 2nd variant to simplify > the codebase when adding the CMake build system. Anyways... The original LTDL > variant adds "SEARCH_LIBDIR" to the search path, which is the install path > for the library. We _could_ just prefix name with the SEARCH_LIBDIR to give > it an absolute path and that'd probably work if you install to a specific > location and never move it, but it will cause the unit tests to fail any > RAR-related tests. A second call to try using absolute path for the build > directory for the library could be added in case the first failed and that'd > get the build to work, though that would hadcode the build directory into the > release materials which is poor form. > > Pending anything more official about the whole static-linking thing with > UnRAR, I don't have a great answer. > > -Micah > >> -----Original Message----- >> From: clamav-devel <clamav-devel-boun...@lists.clamav.net> On Behalf Of >> Mark Allan >> Sent: Tuesday, February 23, 2021 4:33 PM >> To: ClamAV Development <clamav-devel@lists.clamav.net> >> Subject: Re: [Clamav-devel] dlopen using relative path for libclamunrar >> >> Hi Micah, >> >> Many thanks for your reply. I'm always careful to abide by software licences, >> so wouldn't want to build as 'static' if that would be against UnRAR's >> licence. >> >> I'm really just looking for a way to make dlopen load libclamunrar_iface (and >> all/any other libraries) by way of absolute paths instead of relative ones, >> without building as static. Is that at all possible? >> >> Thanks again, >> Mark >> >>> On 23 Feb 2021, at 11:57 pm, Micah Snyder (micasnyd) >> <micas...@cisco.com> wrote: >>> >>> Hi Mark, >>> >>> libclamunrar_iface is loaded dynamically with dlopen and is not linked >>> with libclamav. UnRAR's license is not entirely "free". It restricts >>> against reversing UnRAR to create a RAR archiver. This predates me, >>> but my understanding is this: The intention is to separate libclamav's >>> GPLv2 source so that ClamAV can be distributed by Debian on normal >>> (free software) package servers. Debian distributes the libclamunrar >>> library separately. In this way, ClamAV installed from Debian's >>> `apt-get clamav` can function without RAR support but if RAR support >>> is desired and the user is okay with using "non-free" software, they >>> can enable the non-free packages and install libclamunrar. Eg: >>> https://www.danami.com/clients/knowledgebase/90/How-can-I-enable- >> .rar- >>> support-for-ClamAV.html >>> >>> Of course, if you're building ClamAV for macOS and you have no qualms >> about the free/non-free open source licensing, then perhaps linking >> libclamunrar_iface with libclamav is the way to go. This isn't simple in the >> build system at present but as soon as I merge this work >> (https://github.com/micahsnyder/clamav-devel/tree/CLAM-34-unit-test- >> overhaul-windows-support), it will be as simple as doing a CMake build with >> static enabled and shared disabled: >> https://github.com/micahsnyder/clamav-devel/blob/CLAM-34-unit-test- >> overhaul-windows-support/CMakeLists.txt#L140 I added this capability for >> better code coverage in oss-fuzz, but I imagine it will be good for macOS >> hardened systems as well. >>> >>> On that note, CMake's CPack tool may be used to build installers for >> Windows AND build package installers for macOS as well. Publishing >> Windows installers is something I needed to do for feature parity with our >> old build system, but it's on my to-do list to do the same for macOS, and to >> add it into our internal Jenkins CI pipeline. I suppose I should consider >> making at least the macOS one static. >>> >>> -Micah >>> >>>> -----Original Message----- >>>> From: clamav-devel <clamav-devel-boun...@lists.clamav.net> On Behalf >>>> Of Mark Allan >>>> Sent: Saturday, February 20, 2021 4:43 PM >>>> To: ClamAV Development <clamav-devel@lists.clamav.net> >>>> Subject: [Clamav-devel] dlopen using relative path for libclamunrar >>>> >>>> Hi there, >>>> >>>> Ever since enabling the macOS hardened runtime for ClamAV, I've been >>>> getting the following error/warning message whenever I try to call >>>> any of the ClamAV >>>> binaries: >>>> >>>>> LibClamAV Warning: Cannot dlopen libclamunrar_iface: >>>> dlopen(libclamunrar_iface.a, 2): no suitable image found. Did find: >>>>> file system relative paths not allowed in hardened programs - unrar >>>> support unavailable >>>> >>>> >>>> Is there any reason why the libclamunrar library would be being >>>> referenced via relative path instead of absolute, and is there any way I >> can fix this? >>>> >>>> The other libraries such as libclamav, libclammspack etc appear to load >> fine. >>>> >>>> I'd appreciate any help you can give. >>>> >>>> Thanks >>>> Mark >>>> _______________________________________________ >>>> >>>> clamav-devel mailing list >>>> clamav-devel@lists.clamav.net >>>> https://lists.clamav.net/mailman/listinfo/clamav-devel >>>> >>>> Please submit your patches to our Github: https://github.com/Cisco- >>>> Talos/clamav-devel/pulls >>>> >>>> Help us build a comprehensive ClamAV guide: >>>> https://github.com/vrtadmin/clamav-faq >>>> >>>> http://www.clamav.net/contact.html#ml >>> _______________________________________________ >>> >>> clamav-devel mailing list >>> clamav-devel@lists.clamav.net >>> https://lists.clamav.net/mailman/listinfo/clamav-devel >>> >>> Please submit your patches to our Github: >>> https://github.com/Cisco-Talos/clamav-devel/pulls >>> >>> Help us build a comprehensive ClamAV guide: >>> https://github.com/vrtadmin/clamav-faq >>> >>> http://www.clamav.net/contact.html#ml >> >> _______________________________________________ >> >> clamav-devel mailing list >> clamav-devel@lists.clamav.net >> https://lists.clamav.net/mailman/listinfo/clamav-devel >> >> Please submit your patches to our Github: https://github.com/Cisco- >> Talos/clamav-devel/pulls >> >> Help us build a comprehensive ClamAV guide: >> https://github.com/vrtadmin/clamav-faq >> >> http://www.clamav.net/contact.html#ml > _______________________________________________ > > clamav-devel mailing list > clamav-devel@lists.clamav.net > https://lists.clamav.net/mailman/listinfo/clamav-devel > > Please submit your patches to our Github: > https://github.com/Cisco-Talos/clamav-devel/pulls > > Help us build a comprehensive ClamAV guide: > https://github.com/vrtadmin/clamav-faq > > http://www.clamav.net/contact.html#ml _______________________________________________ clamav-devel mailing list clamav-devel@lists.clamav.net https://lists.clamav.net/mailman/listinfo/clamav-devel Please submit your patches to our Github: https://github.com/Cisco-Talos/clamav-devel/pulls Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml