[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Dazuko-devel] Re: mount/umount events?
From: |
John Ogness |
Subject: |
[Dazuko-devel] Re: mount/umount events? |
Date: |
Wed, 09 Feb 2005 23:28:09 +0100 |
User-agent: |
Mozilla Thunderbird 1.0 (X11/20050201) |
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
- [Dazuko-devel] Re: mount/umount events?,
John Ogness <=