[Dazuko-devel] Re: mount/umount events?

[John Ogness]

Tikka, Sami wrote:
> I have a problem. I have recently realized that in order to maintain a
> consistent user-space scan result cache, the cache needs to be aware of
> changes in the filesystems i.e. mount and umount events.
>
> Without mount/umount events the following would be possible:
>
> 1. Mount a filesystem on a removable media (a cdrom, usb-stick, ...)
>
> 2. Access a file on it. Scan result is cached. The (device, inode) pair is
> used to identify the file.
>
> 3. Umount the filesystem
>
> 4. Replace the removable media with another of the same kind
>
> 5. Mount the new filesystem (presumably containing viruses). The new
> filesystem will have the same device number as the one previously mounted
>
> 6. Access a file (with a virus) with the same inode number as the file in
> step 2 had. The scan result will be found in the cache => BOOM, you're
> infected

Hi,

It would seem to me that if you are caching the results of scanning file 
content, that you should use more than device/inode pairs for 
determining if the cache should be invalidated. Dazuko doesn't detect 
when files are modified, only when they are open/closed (and for Linux 
2.6 only opened). I fail to see how knowing about mount/umount makes 
your solution safer. You have the same problem even if mounting doesn't 
take place.

1. An evil program opens a file (but doesn't do anything with it.. yet).

2. User accesses a file. Scan result is cached. The (device, inode) pair 
is used to identify the file.

3. Evil program writes evil code to file (but doesn't close it, just 
flushes the data).

4. User accesses the file (with a virus) with the same inode number as 
the file in step 2 had. The scan result will be found in the cache => 
BOOM, you're infected

The problem here is not Dazuko, but your criteria for your cache. You 
know that the file is being opened, but you aren't considering its 
content may be different.


> To prevent bad things, the cache would have to be flushed at step 3 or 4. Or
> at least the entries that became invalid by the umount would have to be
> pruned. At first I'm willing to just flush the whole cache.
>
> I have the beginnings of umount/mount implementation already coded. Dazuko
> driver would send DAZUKO_ON_MOUNT and DAZUKO_ON_UMOUNT events and the
> filename in the event would be the mountpoint directory.
>
> Does this sound like something you could integrate into Dazuko?

I have two reasons why I would not like this to be in Dazuko right now:

1. I do not believe that implementing this will solve your problem.

2. The upcoming 2.2.x series of Dazuko is based on a stackable 
filesystem. I am not sure how well I would be able to support 
mount/unmount events with such an architecture. I don't want to 
introduce events into the official API that will be dead in 6 months. (I 
already have enough regrets because of the ON_CLOSE_MODIFIED event.)

I have been thinking about it for a few days now and I will continue 
thinking about it. I am just real skeptical about introducing new events 
right now until we make the move to VFS. (This also applies to your 
suggestion for ON_RESOLVE_LINK events, which only has meaning for Linux 
2.6 LSM.)

John Ogness

--
Dazuko Maintainer