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
--
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
