I have never tried myself, but checking in clamd.conf
file I can see that the size of files can be set manually.
Changing the following values to "n" appears to be the workaround for the file size limit which sets it to unlimited:
-max-filesize=#n
-max-scansize=#n
BytecodeUnsigned yes
http://blog.clamav.net/2014/11/brief-re-introduction-to-clamav.html
However, I know that currently ClamAV has hard file limit to 4GB. However, from my understanding by setting to "n" along with BytecodeUnsigned
to "yes" in config file will do the workaround and of course there are a few particulars to consider before doing that, particulars such as:
- the amount of memory present/available on server should be way bigger than the file size because ClamAV is mapping the file into memory.
- The swap file system, the size of swap fs should be calculated according to the ram size on server (just in case it hits the swap).
If the above to particular are not taken care of it with an extra attention ClamAV won't be able to scan or better, it will eat all of systems memory and therefore killed by OEM Killer.
mmap
takes an offset of typeoff_t
(which is 64-bit) to specify where in the file you want to map from. The process can't map more than about 2.8GB at once, but it can definitely unmap and remap the next chunk. The equivalent in Windows isMapViewOfFile
which also accepts a 64-bit offset. If instead the AV wishes to use traditional file functions (e.g.fopen
) then they can define_FILE_OFFSET_BITS
and usefseek64
. Any restriction to 4GB by the AV is not due to technical restrictions of the operating system.-D_FILE_OFFSET_BITS=64
. However given the way AV detection works it is likely they are maintaining a pointer as a 32 bit unsigned integer rather aoff_t
type..