<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=UTF-8" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> Scott Lovenberg wrote: <blockquote cite="mid:47E732CD.3070202@gmail.com" type="cite">Jörn Engel wrote: <blockquote type="cite">On Sat, 22 March 2008 23:55:53 +0800, Peter Teoh wrote: <blockquote type="cite"> <blockquote type="cite"> Or do you want individual files/directories to be immutable - chattr? </blockquote> chattr is not good enough, as root can still modify it. So if current feature is not there, then some small development may be needed. <blockquote type="cite"> And in either case, what problem do you want to solve with a read-only filesystem? </blockquote> Simple: i want to record down everything that a user does, or a database does, or any applications running - just record down its state permanently securely into the filesystem, knowing that for sure, there is not way to modify the data, short of recreating the filesystem again. Sound logical? Or is there any loophole in this concept? </blockquote> The loophole is called root. In a normal setup, root can do anything, including writing directly to the device your filesystem resides in, writing to kernel memory, etc. It may be rather inconvenient to change a filesystem by writing to the block device, but far from impossible. If you want to make such changes impossible, you are facing an uphill battle that I personally don't care about. And if inconvenience is good enough, wouldn't chattr be sufficiently inconvenient? Jörn </blockquote> How about mounting an isofs via loopback? This has the added benefit of being ready to be exported to disc. You can make it with mkisofs on a directory structure and mount it to the tree with a normal mount(1). If it asks for fs type on mount, I think its 'iso9660'. </blockquote> Thanks for the idea. Based on this idea, I will start looking at the implementation of isofs, and how is it made to be readonly.......my ultimate aim is to make the filesystem readonly upon after being written, and the file closed. Not sure if it can be done, but I envisaged a lot of audit journalling are of these nature. Of course, it is always possible to "dd" the filesystem to modify the content, but then if given design into its protection mechanism (like incremental checksum - current checksum based on previous checksum, generated and stored together with the file, upon after every writing of data) we can always protect its integrity. Aim is to set it to readonly......anyone can read....but not modifiable. As a start I will try out patching ext2, hoping that it is much simpler than ext3/ext4. Upon changes to its content (via dd) it will invalidate the immediate future incremental checksum. Similarly, if u patch the current checksum (which depends on a hash function of previous data, and previous checksum), it will not be valid, as the current checksum is also dependent on the history of previous checksum. So everytime u change the content via dd, u will need to modify the next checksum, which is calculated based on this data, and the current checksum, which again provide the seed for the next checksum etc. U will have to modify a lot of data, unless u are near the tip of the latest modification. The smaller the chunk of data per checksum, the more difficult to keep up with the rate of modification. Tradeoff is more work for CPU. The userspace tool part will then always validate the checksum with the data being read, if modified, checksum will not be valid. Since it is a hash function, given the modified data, and the previous checksum, it is not possible calculate the current checksum. Of course, if the intruder is root, then it is as good as not having all these complex calculations, so our assumption is that the machine is not compromised yet. Then of course the "chattr" can be used as well - if it is not compromised. True, but the possibility that it can be modified infinitely via chattr also exists - which is what write-once-read-many is against - to provide the assurance that it has not been overwritten the second time (possible technically, but very very difficult). An equivalent requirements of such a filesystem will be: a filesystem such that upon every changes made, a log of dates of changes are made. Overhead for these feature is high, so a lightweighted version will be the date/history only it is first written. On an existing ext2 filesystem, once the '"worm" kernel module is loaded, the feature immediately take effect - content becomes read-only but not modifiable, but modifiable for new contents. And old contents may or may not have a checksum to protect it, but if the checksum exists, it will come from the last time "worm" was running and generating checksum. So u have the best of both world - ext2/3/4 with/without worm. If worm-enabled, it may also be configured at the directory level - some directory can be solely dedicated for worm-journalling. What do u guys think - any conceptual errors? </body> </html>