Messages in this thread | | | Date | Thu, 9 Sep 2004 14:39:57 +0200 | From | Pavel Machek <> | Subject | Re: Q about pagecache data never written to disk |
| |
Hi!
> > > The kernel will make one attampt to write the data to disk. If that write > > > hits ENOSPC, the page is not redirtied (ie: the data can be lost). > > > > > > When that write hits ENOSPC an error flag is set in the address_space and > > > that will be returned from a subsequent msync(). The application will then > > > need to do something about it. > > > > > > If your application doesn't msync() the memory then it doesn't care about > > > its data anyway. If your application _does_ msync the pages then we > > > reliably report errors. > > > > This question came to my mind when I was thinking about journal_start in > > ext3_prepare_write and copy_from_user issue... > > Did you follow that discussion? > > Yup. Chris and I have been admiring the problem for a few months now. > > > In the considered scenario not only the application is not > > guaranteed anything till msync(), but all other programs doing regular read() > > may also be fooled about the file content, and this idea surprised me. > > On the other hand, after a write() other programs also see the new content > > without a guarantee that this content corresponds with what is on the disk... > > No, read() will see the modified pagecache data immediately, apart from CPU > cache coherency effects.
Is not this quite a big security hole?
cat evil_data > /tmp/sign.me [Okay, evil_data probably have to contain lot of zeroes?] sync, fill disk or wait for someone to fill disk completely
attempt to write good_data to /tmp/sign.me using mmap
"Hey, root, see what /tmp/sign.me contains, can you make it suid?"
root reads /tmp/sign.me, and sees it is good.
root does chown root.root /tmp/sign.me; chmod 4755 /tmp/sign.me
kernel realizes that there's not enough disk space, and discard changes, therefore /tmp/sign.me reverts to previous, evil, content.
Pavel -- When do you have heart between your knees? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |