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
