Wouldn't you be much better off using /dev/random instead?

[ Reply to This | # ]

"Wouldn't you be much better off using /dev/random instead?"

No, that would actually be terrible. First of all, you shouldn't fill the boot disk of a running machine because it will cause problems, so the hint is a bad idea anyway. However, if you are anxious to do bad stuff like fill your root drive, then you definitely shouldn't do it from /dev/random, because /dev/random requires vastly more CPU power to generate data for than /dev/zero does. If would take few hours to fill a drive from /dev/zero, but it could take a few weeks to fill it from /dev/random.

Also, I don't know if Mac OS X does this, but Linux will sometimes block on reads from /dev/random while it waits for more genuinely random input from the outside world (say mouse movements, or network traffic rates or some such). (This used to cause "depleted entropy pool" problems for ssl and ssh on linux. Sorry for the "in my day" storry, but I remember when I used to use linux to generate SSH keys and I would have to wiggle my mouse around a lot in order to generate ssh keys in a reasonable amount of time. :-)


[ Reply to This | # ]

Yes, I remember when I setup a FreeBSD server ~5 years ago, I got the standard generating key message you would normally get, then something odd telling me to "wiggle my mouse or hit keys on the keyboard". You feel like an idiot standing at a console in the server room, "wiggling the mouse", and banging on the keyboard, with other admins* walking around asking you if you have gone insane.

Its funny now, not so much back then.

* They were Windows admins, I was the *nix admin at that time.

[ Reply to This | # ]

Firstly one does not run this as root. run this as a normal user. The system reserves some space for the root user, and this way you will not run out of disk space for critical system. (At least I know this to be true for reiser, ext3 and ext2 filesystems on Linux.

Secondly, anyone paranoid enough to want to do it should never use /dev/zero (Not even when doing it multiple times) since you can still get the data using forensic techniques. Even if you do this multiple times... some drives with advances caching may not even do the successive writes on a very low level (even with only a small sized disk-cache).

Lastly, yes, /dev/random is more cpu intensive... as for a lot more? No it does not:

I did:
(cat /dev/zero > zero &) ; (cat /dev/random > random &) ; sleep 20 ; killall cat ; ls -l zero random

And it showed:

joseki:~ marius$ ls -la random zero
-rw-r--r-- 1 marius staff 222302208 Apr 24 12:27 random
-rw-r--r-- 1 marius staff 666898432 Apr 24 12:27 zero

So, yes, I would suggest using random... a good system-wide anti-entropic engine should be pretty efficient.


[ Reply to This | # ]

I would think that this could be equally useful using /dev/random or /dev/zero. ramdom would help obscure old data from disk searches. zero would allow for the raw partition to be more easily compressed.

[ Reply to This | # ]

As UNIX SysAdmin, I don't think this makes any sense at all.

First, filling up your drive is a very bad idea, as Rob points out. Many services will stop functioning or exhibit odd behavior.

Secondly, I'm not quite sure what you're trying to do here? Make sure any unused sectors are zero'd out? I'm guessing you're using secure delete already anyways. This just doesn't make any sense. Do you work for the NSA? Didn't think so. You don't need to 'zero' your unused disk space.


P.S. - This '35 pass delete' stuff is B.S. The only way to recover data from a HD after 3 passes is with a team of people and highly specialized hardware. Sorry everybody, but my guess is that your data is not that important. Save your hard drive life and stop using 35-pass deletes. If you have sensitive data, encrypt it using a strong passphrase and you'll be much better off.


---
Nem W. Schlecht
http://geekmuse.net/

[ Reply to This | # ]

Not only is this not a good idea, it doesn't entirely work as advertised. Realize that changes to files are often not written to disk immediately. Instead, they are held in memory (cached) and queued for writing to disk. So, when your cat command dies due to insufficient space, it's likely that some of the writes have not completed. When the file is removed, those writes can be deleted from the queue of pending writes. Consequently, some of the disk blocks will never be overwritten.

Also, many filesystems limit the amount of disk that a regular user (i.e. not root) can write to. For instance, UFS reserves 10% of a filesystem (by default, can be set with tunefs minfree option) for root. This would mean that the above command would fail after writing to 90% of the disk, not 100% (leaving 10% unwritten). Unfortunately, I'm not familiar with the implementation of HFS+, so I can't comment on whether it has similar behavior.

[ Reply to This | # ]

"Do you work for the NSA? Didn't think so. You don't need to 'zero' your unused disk space."

I'm guessing you know the things I'm about to say already and just didn't think about them when you wrote this, but using secure erase means that Finder is configured to do secure erase when it empties the trash. It has no impact on, say Quicken's temporary files in /tmp . File in /tmp are also outside of the user's FileVault (assuming this person is using FileVault). There have also been multiple cases where people have suffered identity theft after their financial information was lifted from old drives despite the fact that it had already been (insecurely) deleted on the old drive.

With that said, FileVault, secure erase, and encrypted VM will cover the vast majority of people's needs. In fact, simple lack of familiarity with HFS+ on the part of thieves will cover a lot. Nonetheless, there are legitimate cases for a non-FBI-employee to want to erase the blank space on a root drive.

[ Reply to This | # ]

some of us do. given, this isn't the best way to go about it, it would help prevent some data recovery.

if you want to use this method, i would recommend booting into single use mode first. (cmd-opt-s)

diskutil is the correct way to do this.

------
Disk Utility Tool
Usage: diskutil secureErase [freespace] level
MountPoint|DiskIdentifier|DeviceNode
Securely erases a disk or its freespace.
Level should be one of the following:
1 - Single-pass randomly erase the disk.
2 - US DoD 7-pass secure erase.
3 - Gutmann algorithm 35-pass secure erase.
Ownership of the affected disk is required.
Example: diskutil secureErase 2 /dev/disk2
Note: Level 2 or level 3 secure erases can take an extremely long time.


[ Reply to This | # ]

er,

diskutil secureErase freespace 1 /dev/xxx



[ Reply to This | # ]

So, if you change the hint to:

cat /dev/zero > /tmp/junk & rm /tmp/junk

then the file will magically disappear as soon as the drive fills up. This is slightly safer since it does not fail if RAM fills up to. For example, there are reasons why a rm call might not complete. In a ram-tight situation (if, say, the filesystem cache were to get rather large), then a fork might fail if there's no room on the swap device for more vm. JP

---
Pell

[ Reply to This | # ]

As robdew pointed out, you can do this with diskutil. A good rule of thumb is that if Disk Utility can do it, diskutil can do it.

In fact, Apple is great at letting you do anything (and more!) from the command line - for example, the 'softwareupdate' command for auto-updates.

[ Reply to This | # ]

The right method to perform this very action is part of diskutil:

diskutil secureErase freespace 1|2|3 /dev/disk#s#

(See the man page on diskutil)

Band-aids never work right. They always peal off!

[ Reply to This | # ]

But that won't work unless you have root access, right?


[ Reply to This | # ]

Not sure if this applies on MacOSxtended, but ext2/3 reserved 5% of space for the root user. If so the rm method would leave 5% untouched if run without privileges.

[ Reply to This | # ]

This command does exactly what Disk Utility does. If your computer crashes during a wipe of the free space, you will find that your hard disk space is reduced. Removing the zeroed file from /tmp (if I remember correctly) will restore the disk space. Try doing it in Disk Utility and watch your disk space shrink.

As others have pointed out, some disk space is reserved for root, and therefore the chance of a crash is minute.

Thanks, robdew, for pointing out the secureErase option of diskutil. Some how I missed that. It does exactly the same thing.

[ Reply to This | # ]

...if you're concerned about running the aforementioned 'erase free space' operation on a 'live' filesystem, you may want to shut down your system and reboot with your OSX install disc and run Disk Utility from there instead.

Or, (in keeping with the spirit of the original hint of using the cmd-line) reboot with your OSX install disc into Single User mode (documented elsewhere) then use the diskutil tip mentioned earlier.

[ Reply to This | # ]