Thank you for any previous suggestions. I would like to ask for more, though, as I attach the following:
================================================================================ Midterm Report ================================================================================ In short, the state of my project is as follows: a) user is able to mark a file with a flag under both ffs and ext2fs b) when a file marked that way is truncated, data blocks are zeroed in a buffer and saved back on the backing store The flag can be set for a file with chflags (eg. "chflags scrub ~/.ssh/id_rsa"). It is an owner-type flag (in contrast to a super-user only). In order to achieve it I have modified: * in user land: - /lib/libutil/stat_flags.c, * in kernel land: - /sys/sys/stat.h, - /sys/ufs/ext2fs/ext2fs_vnops.c. In ext2fs the flag is saved in the file system under ext2 flags and represented as "secure deletion", though it is settable with chflags and visible with "ls -lo". To implement b) the following files have been changed: - /sys/ufs/ext2fs/ext2fs_inode.c, - /sys/ufs/ffs/ffs_inode.c, that is procedures for truncating an inode. Common code is abstracted under /sys/ufs/ within ufs_scrub.h and ufs_scrub.c. The current behavior is that the operation blocks until data blocks are saved back to the backing store and the rest of truncating operation is done. As this can take a long time, I thought of implementing it in a form of a work queue, which would collect block numbers and perform scrubbing one cylinder group (or block) at a time. However, that scrub-behind-like behavior complicated matters greatly and I haven't come up with any usable solution in that fashion yet. When SCRUB_DEBUG option is defined on compilation the mechanism produces some diagnostic messages. With help of the vnd(4), fsdb(8), debugfs(8), dd(1), od(1) and raw device handles I was able to do some testing. After using vnd for a while I though it unnecessary, as for now I am testing on a virtual machine and I can add disks on the virtual machine level. In general, the mechanism appeared to work with deleting a whole file, as well as truncating it to a smaller size. I suspect it to be flawed with a race condition though, in which a thread could see a lot of rubbish near the end of file just before truncation, it needs a little more testing. At first, I planned to introduce a file system mount flag for scrubbing all files when mounted with such, but resigned from the idea as it seems unneeded, therefore code for mounting stayed unchanged. The mechanism does not deal with blocks claimed by snapshots but it looks like it would be desired to include that functionality too, I could try to do so after finishing what I have planned: 1) flash bugs out of current solution, ensure robustness 2) add multi-pass overwrite with a simple prng 3) update documentation I have created a repository hosting code of this project here [1]. [1] https://sourceforge.net/p/fsscrubflags/code/ Przemyslaw Sierocinski
