Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!ihdev!pdg
From: pdg@ihdev.UUCP (P. D. Guthrie)
Newsgroups: net.sources.bugs
Subject: Re: What happens during an unlink(2)
Message-ID: <634@ihdev.UUCP>
Date: Thu, 8-May-86 10:47:02 EDT
Article-I.D.: ihdev.634
Posted: Thu May  8 10:47:02 1986
Date-Received: Sat, 10-May-86 07:11:26 EDT
References: <947@kitty.UUCP> <403@ukecc.UUCP> <979@kitty.UUCP>
Reply-To: pdg@ihdev.UUCP (55224-P. D. Guthrie)
Organization: AT&T Bell Laboratories
Lines: 46
Keywords: Disk blocks sometimes get zeroed

In article <861@ttrdc.UUCP> levy@ttrdc.UUCP (Daniel R. Levy) writes:
>In article <438@ukecc.UUCP>, edward@ukecc.UUCP (Edward C. Bennett) writes:
>>In article <238@chronon.chronon.UUCP>, eric@chronon.UUCP (Eric Black) writes:
>>> >	[discussion of what unlink(2) does]
>>> 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.
>>	You're absolutely right. I never though about that way.
>>Edward C. Bennett
>
>Hmmmm.  Maybe there should be an option to 'rm' to cause it to zero out
>files before unlinking them?  (like rm -e [for erase], similar to VMS's
>DELETE/ERASE)
>
The trouble with this is that is really would have to be an option to
unlink(2), which would make a lot of current software obsolete.  The
only other way would be to have rm directly write to disk,  but there is
too much margin for error or mass destruction here.
>I don't see however, why it would matter whether memory is zeroed upon
>release, as long as it gets zeroed before reallocation by an ordinary user
>(and accesses fail, e.g., with a "bus error," if one is trying to read or
>write outside of one's allocated range).  After all, if you're the administrator
>and can look at the memory contents you can spy on running processes anyway.
>-- 
Pretty much true on a UNIX system, although zeroing memory does make it
harder to spy, but those DOD requirements are generic for all trusted
computer systems, and there are others where it would make moer sense.

> -------------------------------    Disclaimer:  The views contained herein are
>|       dan levy | yvel nad      |  my own and are not at all those of my em-
>|         an engihacker @        |  ployer or the administrator of any computer
>| at&t computer systems division |  upon which I may hack.
>|        skokie, illinois        |
> --------------------------------   Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa,
>						vax135}!ttrdc!levy


-- 

Paul Guthrie		`See the happy moron, he doesn't give a damn.
ihnp4!ihdev!pdg		 I wish I were a moron. My God! Perhaps I am.'