Re: [Clamav-devel] dlopen using relative path for libclamunrar
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) > 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 On Behalf Of >> Mark Allan >> Sent: Wednesday, February 24, 2021 7:22 AM >> To: ClamAV Development >> 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) >> 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 On Behalf >>>> Of Mark Allan >>>> Sent: Tuesday, February 23, 2021 4:33 PM >>>> To: ClamAV Development >>>> 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) >>>> 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 >>
Re: [Clamav-devel] dlopen using relative path for libclamunrar
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 On Behalf Of > Mark Allan > Sent: Wednesday, February 24, 2021 7:22 AM > To: ClamAV Development > 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) > 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 On Behalf > >> Of Mark Allan > >> Sent: Tuesday, February 23, 2021 4:33 PM > >> To: ClamAV Development > >> 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) > >> 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- > >> .r
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) > 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 On Behalf Of >> Mark Allan >> Sent: Tuesday, February 23, 2021 4:33 PM >> To: ClamAV Development >> 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) >> 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
Re: [Clamav-devel] dlopen using relative path for libclamunrar
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 On Behalf Of > Mark Allan > Sent: Tuesday, February 23, 2021 4:33 PM > To: ClamAV Development > 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) > 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 On Behalf > >> Of Mark Allan > >> Sent: Saturday, February 20, 2021 4:43 PM > >> To: ClamAV Development > >> 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 t
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) > 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 On Behalf Of >> Mark Allan >> Sent: Saturday, February 20, 2021 4:43 PM >> To: ClamAV Development >> 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
Re: [Clamav-devel] dlopen using relative path for libclamunrar
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 On Behalf Of > Mark Allan > Sent: Saturday, February 20, 2021 4:43 PM > To: ClamAV Development > 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
Re: [Clamav-devel] dlopen using relative path for libclamunrar
Hi there, On Sun, 21 Feb 2021, Mark Allan wrote: 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 nothing after "did find:" in the message? 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? If you want to stay legal, I'm not sure it's straightforward: https://bugzilla.clamav.net/show_bug.cgi?id=12279 -- 73, Ged. ___ 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] 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
