Re: posix_fallocate

[David Holland <dholland-tech%netbsd.org@localhost>]

On Sun, Nov 17, 2013 at 01:15:14PM +0700, Robert Elz wrote:
 > Alternatively, the system could actually allocate all required blocks at
 > the time of the posix_fallocate() call - effectively filling in any holes
 > in the designated region of the file.   The spec doesn't say what data is
 > to be put in the blocks allocated to fill the holes (a well behaved
 > application wouldn't care, as it would normally write to the file before
 > reading it, and would be using fallocate to guarantee that the entire set
 > of write sys call it needed to make would succeed (or the fallocate()
 > would fail), and the system could not run out of space half way through.)

Holes in a file read as zeros, and providing backing for the holes
shouldn't change that. Arguably not referencing this property is a bug
in the standard, but I think it's pretty clear what the intended
behavior is.

 > a trivial DoS attack like ....
 > 
 >      for (;;) {
 >              ftruncate(fd);
 >              posix_fallocate(fd, (off_t)0, huge);
 >      }

I don't see how this is a DoS attack that e.g. dd if=/dev/urandom
of=/dev/null isn't. The write loop is in the kernel, but we're no
longer in the days of nonpreemptible uniprocessor kernels, so it
shouldn't matter much.

-- 
David A. Holland
dholland%netbsd.org@localhost