Re: Q about pagecache data never written to disk

[Pavel Machek <pavel@ucw.cz>]

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?