Unionfs [LWN.net]

Unionfs

Posted Jan 11, 2007 9:50 UTC (Thu) by dlang (✭ supporter ✭, #313)
In reply to: Unionfs by k8to
Parent article: Unionfs

writing to the underlying filesystem is conceptually the same as writing to /dev/hda1 while you have it mounted.

in both cases the filesystem on top doesn't know about the changes below it and can be (fatally) surprised when it finds them.

later messages in the thread indicate that the warning is (somewhat) intentially overstateing the risk of an oops (rather then going into many pages of quickly obsolete details of what will fail)

I suspect that you get away with it by the fact that you are doing read-only on the result.

(Log in to post comments)

Unionfs

Posted Jan 13, 2007 0:33 UTC (Sat) by giraffedata (subscriber, #1954) [Link]

later messages in the thread indicate that the warning is (somewhat) intentionally overstating the risk of an oops

Do you mean the warning is a lie and it is not in fact possible by design to oops the kernel by modifying an underlying filesystem?

Because that's the only way it's sensible. You cannot oops the kernel by writing to /dev/hda1 while an ext3 filesystem on /dev/hda1 is mounted. You can trash unlimited amounts of data, but as the filesystem is external to the kernel, the kernel is robust to whatever bits it might read from it at any time.

Unionfs

Posted Jan 13, 2007 4:52 UTC (Sat) by raven667 (subscriber, #5198) [Link]

You cannot oops the kernel by writing to /dev/hda1 while an ext3 filesystem on /dev/ hda1 is mounted. You can trash unlimited amounts of data, but as the filesystem is external to the kernel, the kernel is robust to whatever bits it might read from it at any time.

That seems like how it should be but I doubt that this is true. In fact I believe one of the major fixes in 2.6.19.2 is CVE-2006-5823 a problem where a corrupte cramfs could OOPS the kernel. This same kind of think can, has and will continue to happen in the filesystem, USB, network, Firewire, block device and other subsystems where bogus data from a piece of hardware isn't sufficiently checked before being used and causes an OOPS (with potential security implications.