When trying to hunt a bug in dmsdos, I ran into a problem with the FAT
driver. Well, meanwhile I think this is not a problem of the FAT driver,
but may be a more general problem, probably affecting other filesystems,
too. It seems, that under some circumstances, the FAT driver or something
at a higher level (probably VFS) can write to a device though it is mounted
read-only.
I only found to trigger that problem reliably by mounting a slightly damaged
filesystem, but there may be other situations that can trigger it too.
In detail, if the driver accesses a damaged directory where the "." and ".."
entries are not present, it tries to remove that directory and pokes around
in the FAT, making things worse. This happens even when the disk is mounted
_read-only_.
To reproduce the problem, I did is this: I formatted a dos floppy, copied
some directory tree (unimportant) to it, created an empty directory,
and then took my good old disk editor in order to zero out the "." and
".." entries of that empty directory. Then I put the write-protect switch to
the floppy and mounted it under Linux.
The system did not crash or hang, but tried to write to the floppy
(according to syslog error messages for trying to write to a read-only
device).
Well this made me curious, so I saved a copy of the raw floppy to a file,
removed the write-protect switch, and mounted the floppy again, read-only.
This time it really wrote to the floppy. It cleared the FAT
entry for the bad directory in both FATs. Though the floppy was mounted
read-only. Uhh...
The reason for this strange behaviour is probably the following: Pavel,
co-maintainer of dmsdos, found that the damaged directory has a link count
value of zero. That makes the VFS layer think the directory inode is to be
removed, which in turn calls fat_truncate. But the code never checks
whether the filesystem is mounted read-only. The kernels I tried are
2.0.35, 2.0.36 and 2.1.128, Pavel also tried 2.1.131.
I'm not sure about other consequences of this problem, but I am _highly_
_concerned_ about the fact that a read-only mounted floppy can be modified
during filesystem access. My suggestion for a quick fix, for the FAT driver,
is just add a line to fat_truncate to check for the MS_RDONLY flag in
inode->i_sb->s_flags and abort fat_truncate immediately if the flag is set.
But maybe a fix at VFS layer is better or even required in this situation.
If it is important, I have saved a raw image of the floppy that triggers
the problem :)
With best wishes for 1999 -
Frank
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/