On 6/18/06, Pablo Marmn Ramsn <[EMAIL PROTECTED]> wrote:
Let's suppose block A contains user A's private data. User A deletes the file, so synchronously the metadata referring to that file is updated, but the data block still contains the sensitive information. Now user B creates a new file B. Let's suppose the data block allocated for file B is block A. The right thing to do in terms of security is first update block A with the new data, and then update the metadata referring to it. But if metadata is updated synchronously first (the free block bitmap says that block A is allocated and the inode of file B points to it) and the system crashes, user B has access to user A's private data. In this case (asynchronous data block updates), fsck cannot fix the problem (if I'm missing something, please correct me).
yes, in the case of ffs without softupdates, i believe it is possible to read from a previously allocated block. since everybody should be using softupdates, this shouldn't be much of a real problem.
The following is extracted from "Soft Updates: A Technique for Eliminating Most Synchronous Writes in the Fast Filesystem": "When a new block is allocated, its bitmap location is updated to reflect that it is in use and the block's contents are initialized with newly written data or zeros. In addition, a pointer to the new block is added to an inode or indirect block (see bellow). To ensure that the on-disk bitmap always reflects allocated resources, the bitmap must be written to disk before the pointer. Also, because the contents of the newly allocated disk location are unknown, rule #1 specifies an update dependency between the new block and the pointer to it. Because enforcing this update dependency with synchronous writes can reduce data creation throughput by a factor of two [Ganger & Patt, 1994], many implementations ignore it for regular data blcosk. This implementation decision reduces integrity and security, since newly allocated blocks generally contain previously deleted file data."
