Messages in this thread | | | From | Frank Gockel <> | Subject | write access to read-only mounted device, uhh | Date | Fri, 8 Jan 1999 18:32:28 +0100 (MET) |
| |
Hi all,
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/
| |