>> other times you talk about a filesystem that can be updated, ... > >NO updating is possible. I'm still not convinced you mean that, because the example you give is specifically of a file that becomes immutable after some writing to it. How about creating a new file? That is a filesystem update. Do you want to allow that? How about directory modifications, such as rename and unlink? >Once the file is open for write, it is possible to >continuosly write to it. But once close, it automatically becomes >read-only. But permanently no userspace tool can reverse the read-only >attribute - controlled from the kernel. But while being opened and >written, it is not possible to move back the file pointer as well - ie, >once written, is written, not possible to overwrite. Concurrently, >other files can be opened on the same directory for writing. Can any >of the abovementioned userspace tool, or existing ext2/3/4 configuration >can satisfy the above requirement? No. And the first thing in the list to which you refer is what I believe your proposal is: adding a feature to ext3. Modifying ext3 cannot satisfy the above requirements. >hash_functionA(checksumA, dataA) ==> checksumB. > >hash_functionA(checksumB, dataB) ==> checksumC. > >hash_functionA(checksumC, dataC) ==> checksumD. >So if u really want to modify a single bytes of data, u have to start >from the very first item in the chain. Yeah, that's what the bad guy will do. So you haven't prevented someone from undetectably modifying previously written data. >And with an added "salt" to the >hash_functionA (random number) The bad guy would be sure to use the same salt, or change it. -- Bryan Henderson IBM Almaden Research Center San Jose CA Filesystems -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
