Re: "Write once only but read many" filesystem

[Peter Teoh <htmldeveloper@gmail.com>]

Bryan Henderson wrote:
> You're still being really vague on your requirements.  Sometimes you talk 
> about a filesystem that can't be modified after it has been written, and 
>   
Sorry for the confusion.   The requirement from upfront is that it is 
ALWAYS WRITE-ONCE only.   But many of you will say that it is 
impossible, as it can be written over again via other means.   Yes, the 
other means is via "dd", but that will require that you unmount the 
filesystem first, then using dd and hexeditor to modify the 
filesystem.   Not sure if I had made myself clear?

> other times you talk about a filesystem that can be updated, but only to 
>   

NO updating is possible.   Write once, and the file attributes defined 
from the first time it is written, and not modifiable after that - 
access control is from the kernel, and therefore userspace cannot do 
anything, once mounted of course.
> add information.  Sometimes you talk about a read-only restriction that is 
> effective against the superuser (not possible) and other times say that 
> it's OK if the superuser can modify the filesystem without a trace.
> In addition to new ext3 features, using isofs, and chattr, mounting 
> read-only and using file permissions also effect read-only status, and 
> you'd have to explain how any of these don't meet your requirements.  But 
>   
May be I will describe an auditing scenario to make myself clear - why 
the above does not meet the requirement.   First, an arbitrary 
application does something, then the auditing daemon will record it 
down, into a file.   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?

> rest assured that none of them is effective against the superuser.
>
>   
Agreed - once the filesystem is unmounted, u can do anything to the 
filesystem.   But modifying any bytes of it will be difficult, the 
control mechanism as laid out in my earlier email.

>> Upon changes to its content (via dd) it will invalidate the immediate 
>> future incremental checksum.
>>     
>
> I couldn't tell what "it" is in this sentence, or what checksums you're 
> thinking of.
>
>   
Erh......Not sure what u mean?   What I mean is that if u unmount the 
filesystem, and attempt to modify any bytes of the write-once 
filesystem, it will most likely invalidate the integrity of subsequent 
data, illustrated by following diagram:

hash_functionA(checksumA, dataA) ==> checksumB.

hash_functionA(checksumB, dataB) ==> checksumC.

hash_functionA(checksumC, dataC) ==> checksumD.

Eg, if u attempt to modify the checksumB, 2 ways of detection is possible:

1.   next:   u can be detected by a mismatch of checksumC stored on the 
disk.  
2.   previous:   u can be detected by a mismatch of checksumB stored on 
disk (based on previous checksumA and dataA).

Or if u attempt to modify the dataB, similarly the two ways of detection 
applies as well.

So if u really want to modify a single bytes of data, u have to start 
from the very first item in the chain.   And with an added "salt" to the 
hash_functionA (random number), it is possible to branch off the 
hash_functionA(checksumB, dataB) into many different branches, thus 
implementing the concurrent open files concept.   And the algorithm of 
calculation as described easily facilitate a forward looking concept - 
no previous data have to be modified - so whatever written on disk, will 
be written, not modifiable anymore.

Is the concept clearer now?

> --
> Bryan Henderson                     IBM Almaden Research Center
> San Jose CA                         Filesystems
>
>
>
>