On Tue, Mar 25, 2008 at 08:47:16AM +0800, Peter Teoh wrote: > 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? You're confused. The kernel cannot prevent root from modifying a block device while a filesystem is mounted. Sounds to me like what you really want is a printer. You can't modify what's been printed. You could also use a second computer and log to that. > 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? Can't be done. root can ptrace the auditing daemon and change what it wants to write. -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." -- 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
