Hi Micah, OK, I've had another look at it, removed the hard-coded paths and cleaned it up a bit. Patch attached.
Hope it's useful. Mark
abspath.patch
Description: Binary data
> On 24 Feb 2021, at 5:00 pm, Micah Snyder (micasnyd) <micas...@cisco.com> > wrote: > > Hi Mark, > > You're welcome! > > Sure, please send a patch my way. I'd prefer if no one had to apply patches > to use ClamAV, so getting those things working upstream is ideal. > > -Micah > >> -----Original Message----- >> From: clamav-devel <clamav-devel-boun...@lists.clamav.net> On Behalf Of >> Mark Allan >> Sent: Wednesday, February 24, 2021 7:22 AM >> To: ClamAV Development <clamav-devel@lists.clamav.net> >> Subject: Re: [Clamav-devel] dlopen using relative path for libclamunrar >> >> 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/o >>> thers.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 > _______________________________________________ > > 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
