so, I dont want other applications to have a chance to try to read any files on the pendrive partition.

from here, after testing (without mounting any partition), I see I can extract the MBR for example, but I wont do that with my pendrive partition of 4GB...

so I wonder if we can scan it without mounting it? like I did with the MBR but without extracting it neither.

Is it possible? May be some other virus scanner could be an option too if clamav cant, or if I can use some linux trick to let it scan without mounting.

This question differs from: https://security.stackexchange.com/a/40008/142551
That requires it to be mounted (but even mounted I couldnt scan neither the MBR neither the partition). As I am trying to scan WITHOUT mounting the partition.

  • Why do you want this? Do you want to protect yourself against bugs in the filesystem implementation?
    – Sjoerd
    Commented Mar 21, 2017 at 10:19
  • @Sjoerd no, its about other nosy apps .. Commented Mar 21, 2017 at 12:05

1 Answer 1


Well you can... provided you mimic the mount of the partition!

At a low level, mounting a partition is no more that reading the raw partition to discover and load its different system tables (allocation table, root folder, etc.). From that point, the system is able to give you access to the individual files.

If for any reason you do not want the kernel to mount the partition, your application must have enough knowledge on the internals of its file system to be able to:

  • find and read the root folder (and any other folder once you can find it)
  • identify all active (plain) files and folders inside a folder
  • load a file from a folder

As you just want to pass clamav there, you can safely ignore all special files (devices, symlinks, unix domain sockets) and only process plain files and folders. Also, you can ignore any file attributes.

Then, you recursively walk the folders, read individually all files and pass their content to clamav

But the question is now: what is the security gain/loss regarding a normal mount of the partition?


  • no risk of accidentally executing anything from the partition
  • no risk of hitting a security flaw in the file system driver(*) (note that you can mediate that with a FUSE driver if there is one, or by running the analysis on a virtual machine)
  • no risk that a third party process can access any file from the partition


  • you must implement securely all the low level structures and accesses of a file system
  • you must trust more your code that the (highly tested) kernel and driver code
  • you must ensure that your code will follow all possible evolutions of the file system
  • you must implement all file systems that you want to be able to clamax

That being said, that is exactly what the fsck utility does: it reads a raw partition and walk along its hierarchy to discover and fix low level errors. But it is a low level system tool...

TL/DR: unless you are a file system expert, I am not sure that the security gain is worth it. IMHO the following procedure should be secure enough:

  • fsck the partition - if it is supported by fsck
  • mount it to a subdirectory of a directory with permissions 700 to make sure that no non root process can access it, with the noexec, nosymfollow, noatime flags
  • pass clamav on it

(*) mount man page ends with

It is possible for a corrupted file system to cause a crash.

  • so basically, a highly restricted access and still mounting alternative (instead of the default generic access mount mode), that sounds quite good, I will have to test it, thx! Commented Mar 21, 2017 at 12:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .