User: Password:
Subscribe / Log in / New account

Allocating uninitialized file blocks

Allocating uninitialized file blocks

Posted Apr 19, 2012 7:15 UTC (Thu) by slashdot (guest, #22014)
Parent article: Allocating uninitialized file blocks

This is something that should never be done unless the benefit is truly huge it is mathematically provable that there's no other way to achieve it.

Even if an application has root privileges, a bug in it (even just not zeroing out padding in a structure) may result in an accidental leak of data from a totally unrelated file to a remote client.

The only sensible variant is zeroing blocks from deleted files in the background and only using those scrubbed blocks.

(Log in to post comments)

Allocating uninitialized file blocks

Posted Apr 19, 2012 15:35 UTC (Thu) by jzbiciak (subscriber, #5246) [Link]

How is this at all different than just opening up the device node associated with the partition? If you're root, what's stopping you?

As Ted Ts'o suggested, if a process has the capability to do raw I/O, why not let it see raw disk blocks occasionally? You've already given it permission to do low level I/O in spite of a filesystem, so what's the harm in letting it stale blocks within a filesystem?

Allocating uninitialized file blocks

Posted Apr 19, 2012 19:28 UTC (Thu) by nybble41 (subscriber, #55106) [Link]

The problem is that while a root process or one with raw I/O capabilities can see those blocks itself, it wouldn't usually write them out to a file which other users could read. However, if a root process allocates space for a file readable by non-root processes, and that space remains uninitialized, the other processes will have access to the former contents of those blocks.

Allocating uninitialized file blocks

Posted Apr 20, 2012 5:41 UTC (Fri) by jzbiciak (subscriber, #5246) [Link]

Well, this new fallocate() feature is explicit. It's not like we're suddenly changing the semantics of holes in files. It's really about policy vs. mechanism. We need to ask if this is a useful mechanism, and if so, can user space use it safely if it adopts appropriate polices?

The definition of "appropriate policy" depends entirely on the usage scenario and security requirements of the system and application. A DVR disk that has nothing but video files on it won't leak anything interesting, so this fallocate() mode may be perfectly suited to it, for example, assuming a bittorent-style scattered download.

All that said, this new mode does need to prove its usefulness. If the performance issue is unique to ext4, then it's probably better to just fix ext4.

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds