Unionfs [LWN.net]

Unionfs

Posted Jan 11, 2007 8:07 UTC (Thu) by k8to (subscriber, #15413)
Parent article: Unionfs

Huh, I modify the contents of a branch out from under a union mount just about every day. In fact, that's the only way I ever modify it.

I have yet to see a single oops or data loss problem.

Surely there must be more to triggering this problem.

(Log in to post comments)

Unionfs

Posted Jan 11, 2007 9:50 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]

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.

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.