edward@ukecc.UUCP (Edward C. Bennett) (04/27/86)
In article <979@kitty.UUCP>, larry@kitty.UUCP writes: >In article <403@ukecc.UUCP>, edward@ukecc.UUCP (Edward C. Bennett) writes: >> >> But you can recover an unlinked file! I know, I've had to do it. >> You must unmount the file system and search the free list for your data. >> It's a PITA, but worth it if you lose something big. > > I don't claim to be a UNIX internals expert (I have enough trouble > writing I/O drivers :-) ), but don't most ports of UNIX zero disk blocks after > an unlink(2)? As I seem to recall, unlink(2) is derived from unlink.s, which > is assembly language specific for the given machine. And unlink.s contains > a routine _unlink which fills the disk blocks with .word defined as 0x0000. When you unlink a file, the disk block addresses in the inode are zeroed, not the actual data blocks. Zeroing the inode is tantamount to 'forgetting' where the data is actually stored. The 'forgotten' data blocks are added to the (top of the) free list to be used when adding data to the filesystem. When the old data blocks are placed in the free list, their contents are unimportant. Zeroing the blocks would be a waste of time since whatever is there will be overwritten when the blocks are allocated to another file. This situation is identical to the malloc()/free() process. i.e. Space that has been malloc()ed will have data written into it. When this space is free()ed, the data in it is not altered and is useable until the next malloc(). -- Edward C. Bennett UUCP: ihnp4!cbosgd!ukma!ukecc!edward Kentucky: The state that is being dragged, kicking and screaming, into the 20th century. "Goodnight M.A."
wcs@ho95e.UUCP (#Bill_Stewart) (04/30/86)
In article <422@ukecc.UUCP> edward@ukecc.UUCP (Edward C. Bennett) writes: > >>.....[stuff about what happens to blocks when you unlink the file]... > When the old data blocks are placed in the free list, their contents >are unimportant. Zeroing the blocks would be a waste of time since whatever >is there will be overwritten when the blocks are allocated to another file. >This situation is identical to the malloc()/free() process. i.e. Space >that has been malloc()ed will have data written into it. When this space >is free()ed, the data in it is not altered and is useable until the next >malloc(). Please don't depend on this behaviour! Under the older mallocs (including System V and 4.1BSD), you could depend on it, but systems with newer and fancier mallocs don't promise it. In particular, System V Release 2 offers two malloc routines. The default is the old malloc, but the new -lmalloc library provides routines that offer better performance under some kinds of input, and the man page says you can't trust freed-up memory after a free() or realloc(). In general, the safety of using freed space depends on the implementation of the data structures chaining space together. -- # Bill Stewart, AT&T Bell Labs 2G-202, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs
eric@chronon.UUCP (Eric Black) (05/01/86)
In article <422@ukecc.UUCP> edward@ukecc.UUCP (Edward C. Bennett) writes: > >In article <979@kitty.UUCP>, larry@kitty.UUCP writes: >> >> I don't claim to be a UNIX internals expert (I have enough trouble >> writing I/O drivers :-) ), but don't most ports of UNIX zero disk blocks after >> an unlink(2)? As I seem to recall, unlink(2) is derived from unlink.s, which >> is assembly language specific for the given machine. And unlink.s contains >> a routine _unlink which fills the disk blocks with .word defined as 0x0000. > > When you unlink a file, the disk block addresses in the inode are >zeroed, not the actual data blocks. Zeroing the inode is tantamount to >'forgetting' where the data is actually stored. The 'forgotten' data >blocks are added to the (top of the) free list to be used when adding data >to the filesystem. > When the old data blocks are placed in the free list, their contents >are unimportant. Zeroing the blocks would be a waste of time since whatever >is there will be overwritten when the blocks are allocated to another file. >This situation is identical to the malloc()/free() process. i.e. Space >that has been malloc()ed will have data written into it. When this space >is free()ed, the data in it is not altered and is useable until the next >malloc(). Some unitory systems do, indeed, zero out disk blocks when de-allocated, and similarly clear memory when freed. Any system you sell to customers with concerns about security will require this. Check out DOD requirements for secure systems in the "Department of Defense Trusted Computer System Evaluation Criteria", publication CSC-STD-001-83 (my copy is dated March 1985) for this and other interesting features... Spooks aren't the only people who might desire disks & memory to be cleansed when released, by the way. * "unitory" is a trademark of absolutely nobody, and I like it! -- Eric Black "Garbage In, Gospel Out" UUCP: {sun,pyramid,hplabs,amdcad}!chronon!eric WELL: eblack BIX: eblack
barmar@mit-eddie.MIT.EDU (Barry Margolin) (05/02/86)
In article <238@chronon.chronon.UUCP> eric@chronon.UUCP (Eric Black) writes: >Some unitory systems do, indeed, zero out disk blocks when de-allocated, >and similarly clear memory when freed. Any system you sell to customers >with concerns about security will require this. Check out DOD requirements >for secure systems in the "Department of Defense Trusted Computer >System Evaluation Criteria", publication CSC-STD-001-83 (my copy is >dated March 1985) for this and other interesting features... I don't have my copy of the Criteria handy, but I don't believe that it requires zeroing of freed disk blocks (I'm pretty sure that we don't zero freed disk blocks on Multics, and we are rated B2). What it requires is that the old data not be accessible upon reuse. A freed disk block will never be paged into memory, and when it is reused it will be completely overwritten by the memory frame being paged out. And an unused physical memory frame will be zeroed before being allocated into the page table (but not if the frame is being allocated to hold a disk page being read in). Working from memory, I think the only requirement about zeroing has to do with removable media. The system must be able to completely destroy the data upon request. For example, we have a tape drive operation (called "data security erase", I think) that overwrites every record of the tape several times, to make sure that that no residual data can be detected. -- Barry Margolin ARPA: barmar@MIT-Multics UUCP: ..!genrad!mit-eddie!barmar
jgy@hropus.UUCP (jgy) (05/07/86)
Someone said: > When you unlink a file, the disk block addresses in the inode are > zeroed, not the actual data blocks. Zeroing the inode is tantamount to > 'forgetting' where the data is actually stored. .............. This is not true, all that is necessary is that the blocks be put on the freelist, the inode marked unallocated and added to the inode freelist. If this were the case you could just go and look at your unallocated inode for the block information. The onus would be on the system to clear the inode before being reused. The only possible dispute I can see with this is (problems with a crash can be handled) that of who should be "charged" with clearing of someone else's dirty inode!
dave@onfcanim.UUCP (Dave Martindale) (05/08/86)
In article <442@hropus.UUCP> jgy@hropus.UUCP (jgy) writes: >Someone said: >> When you unlink a file, the disk block addresses in the inode are >> zeroed, not the actual data blocks. Zeroing the inode is tantamount to >> 'forgetting' where the data is actually stored. .............. > >This is not true, all that is necessary is that the blocks be put on the >freelist, the inode marked unallocated and added to the inode freelist. >If this were the case you could just go and look at your unallocated inode >for the block information. The onus would be on the system to clear the >inode before being reused. The only possible dispute I can see with this >is (problems with a crash can be handled) that of who should be >"charged" with clearing of someone else's dirty inode! There is still a way of getting back most of the data of a just-deleted file on an inactive filesystem: the data blocks have just been put onto the freelist, and 99/100 of them still have their original data in them. Just poke through the first blocks of the free list to get your data. If someone has already allocated the blocks to a new file (by writing on them), tough luck. This generally will happen within a few seconds, so there seems little point in writing out inodes with the block pointers still intact - it will seldom do you much good. But you have to modify the inode on disk anyway, to make sure it is marked free in case a crash happens, and if you're going to modify even one bit of it you might as well zero the whole thing - the cost is primarily in the disk I/O and copying.