> >I agree that unionfs shouldn't oops, it should handle that situation in >a more graceful manner, but once the "backing store" is modified >underneath it, all bets are off for either unionfs or ext2/3 behaving >"correctly" (where "correctly" doesn't just mean handle the error >gracefully). > >But are you also 100% sure that messing with the underlying backing >store wouldn't be considered an admin bug as opposed to an administrator >bug? I mean there's nothing that we can do to prevent an administrator >from FUBAR'ing their system by > >dd if=/dev/random of=/dev/kmem. > >where does one draw the line? I agree that stackable file systems make >this a more pressing issue, as the "backing store" can be visible within >the file system namespace as a regular file system that people are >generally accustomed to interacting with. So here's an idea. When a branch is added, mount an empty space onto the branch. (From within the kernel, so it appears as a side-effect of mount(2)) mount -t unionfs -o dirs=/a=rw:/b=ro none /union should imply something like mount --bind /var/lib/empty /a mount --bind /var/lib/empty /b Or better, yet, make them read-only: mount --rbind -o ro /a /a mount --rbind -o ro /b /b (hope this works as intended?) So that no one can tinker with /a and /b while the union is mounted. Jan Engelhardt -- - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
