coreutils: shred invocation
1
1 11.6 ‘shred’: Remove files more securely
1 ========================================
1
1 ‘shred’ overwrites devices or files, to help prevent even very expensive
1 hardware from recovering the data.
1
1 Ordinarily when you remove a file (⇒rm invocation), the data
1 is not actually destroyed. Only the index listing where the file is
1 stored is destroyed, and the storage is made available for reuse. There
1 are undelete utilities that will attempt to reconstruct the index and
1 can bring the file back if the parts were not reused.
1
1 On a busy system with a nearly-full drive, space can get reused in a
1 few seconds. But there is no way to know for sure. If you have
1 sensitive data, you may want to be sure that recovery is not possible by
1 actually overwriting the file with non-sensitive data.
1
1 However, even after doing that, it is possible to take the disk back
1 to a laboratory and use a lot of sensitive (and expensive) equipment to
1 look for the faint “echoes” of the original data underneath the
1 overwritten data. If the data has only been overwritten once, it’s not
1 even that hard.
1
1 The best way to remove something irretrievably is to destroy the
1 media it’s on with acid, melt it down, or the like. For cheap removable
1 media like floppy disks, this is the preferred method. However, hard
1 drives are expensive and hard to melt, so the ‘shred’ utility tries to
1 achieve a similar effect non-destructively.
1
1 This uses many overwrite passes, with the data patterns chosen to
1 maximize the damage they do to the old data. While this will work on
1 floppies, the patterns are designed for best effect on hard drives. For
1 more details, see the source code and Peter Gutmann’s paper ‘Secure
1 Deletion of Data from Magnetic and Solid-State Memory’
1 (https://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html), from the
1 proceedings of the Sixth USENIX Security Symposium (San Jose,
1 California, July 22–25, 1996).
1
1 *Please note* that ‘shred’ relies on a very important assumption:
1 that the file system overwrites data in place. This is the traditional
1 way to do things, but many modern file system designs do not satisfy
1 this assumption. Exceptions include:
1
1 • Log-structured or journaled file systems, such as those supplied
1 with AIX and Solaris, and JFS, ReiserFS, XFS, Ext3 (in
1 ‘data=journal’ mode), BFS, NTFS, etc., when they are configured to
1 journal _data_.
1
1 • File systems that write redundant data and carry on even if some
1 writes fail, such as RAID-based file systems.
1
1 • File systems that make snapshots, such as Network Appliance’s NFS
1 server.
1
1 • File systems that cache in temporary locations, such as NFS version
1 3 clients.
1
1 • Compressed file systems.
1
1 In the particular case of ext3 file systems, the above disclaimer
1 applies (and ‘shred’ is thus of limited effectiveness) only in
1 ‘data=journal’ mode, which journals file data in addition to just
1 metadata. In both the ‘data=ordered’ (default) and ‘data=writeback’
1 modes, ‘shred’ works as usual. Ext3 journaling modes can be changed by
1 adding the ‘data=something’ option to the mount options for a particular
1 file system in the ‘/etc/fstab’ file, as documented in the mount man
1 page (man mount).
1
1 If you are not sure how your file system operates, then you should
1 assume that it does not overwrite data in place, which means that shred
1 cannot reliably operate on regular files in your file system.
1
1 Generally speaking, it is more reliable to shred a device than a
1 file, since this bypasses the problem of file system design mentioned
1 above. However, even shredding devices is not always completely
1 reliable. For example, most disks map out bad sectors invisibly to the
1 application; if the bad sectors contain sensitive data, ‘shred’ won’t be
1 able to destroy it.
1
1 ‘shred’ makes no attempt to detect or report this problem, just as it
1 makes no attempt to do anything about backups. However, since it is
1 more reliable to shred devices than files, ‘shred’ by default does not
1 deallocate or remove the output file. This default is more suitable for
1 devices, which typically cannot be deallocated and should not be
1 removed.
1
1 Finally, consider the risk of backups and mirrors. File system
1 backups and remote mirrors may contain copies of the file that cannot be
1 removed, and that will allow a shredded file to be recovered later. So
1 if you keep any data you may later want to destroy using ‘shred’, be
1 sure that it is not backed up or mirrored.
1
1 shred [OPTION]... FILE[...]
1
11 The program accepts the following options. Also see ⇒Common
options.
1
1 ‘-f’
1 ‘--force’
1 Override file permissions if necessary to allow overwriting.
1
1 ‘-n NUMBER’
1 ‘--iterations=NUMBER’
1 By default, ‘shred’ uses 3 passes of overwrite. You can reduce
1 this to save time, or increase it if you think it’s appropriate.
1 After 25 passes all of the internal overwrite patterns will have
1 been used at least once.
1
1 ‘--random-source=FILE’
1 Use FILE as a source of random data used to overwrite and to choose
1 pass ordering. ⇒Random sources.
1
1 ‘-s BYTES’
1 ‘--size=BYTES’
1 Shred the first BYTES bytes of the file. The default is to shred
1 the whole file. BYTES can be followed by a size specification like
1 ‘K’, ‘M’, or ‘G’ to specify a multiple. ⇒Block size.
1
1 ‘-u’
1 ‘--remove[=HOW]’
1 After shredding a file, deallocate it (if possible) and then remove
1 it. If a file has multiple links, only the named links will be
1 removed. Often the file name is less sensitive than the file data,
1 in which case the optional HOW parameter, supported with the long
1 form option, gives control of how to more efficiently remove each
1 directory entry. The ‘unlink’ parameter will just use a standard
1 unlink call, ‘wipe’ will also first obfuscate bytes in the name,
1 and ‘wipesync’ will also sync each obfuscated byte in the name to
1 disk. Note ‘wipesync’ is the default method, but can be expensive,
1 requiring a sync for every character in every file. This can
1 become significant with many files, or is redundant if your file
1 system provides synchronous metadata updates.
1
1 ‘-v’
1 ‘--verbose’
1 Display to standard error all status updates as sterilization
1 proceeds.
1
1 ‘-x’
1 ‘--exact’
1 By default, ‘shred’ rounds the size of a regular file up to the
1 next multiple of the file system block size to fully erase the
1 slack space in the last block of the file. This space may contain
1 portions of the current system memory on some systems for example.
1 Use ‘--exact’ to suppress that behavior. Thus, by default if you
1 shred a 10-byte regular file on a system with 512-byte blocks, the
1 resulting file will be 512 bytes long. With this option, shred
1 does not increase the apparent size of the file.
1
1 ‘-z’
1 ‘--zero’
1 Normally, the last pass that ‘shred’ writes is made up of random
1 data. If this would be conspicuous on your hard drive (for
1 example, because it looks like encrypted data), or you just think
1 it’s tidier, the ‘--zero’ option adds an additional overwrite pass
1 with all zero bits. This is in addition to the number of passes
1 specified by the ‘--iterations’ option.
1
1 You might use the following command to erase all trace of the file
1 system you’d created on the floppy disk in your first drive. That
1 command takes about 20 minutes to erase a “1.44MB” (actually 1440 KiB)
1 floppy.
1
1 shred --verbose /dev/fd0
1
1 Similarly, to erase all data on a selected partition of your hard
1 disk, you could give a command like this:
1
1 shred --verbose /dev/sda5
1
1 On modern disks, a single pass should be adequate, and it will take
1 one third the time of the default three-pass approach.
1
1 # 1 pass, write pseudo-random data; 3x faster than the default
1 shred --verbose -n1 /dev/sda5
1
1 To be on the safe side, use at least one pass that overwrites using
1 pseudo-random data. I.e., don’t be tempted to use ‘-n0 --zero’, in case
1 some disk controller optimizes the process of writing blocks of all
1 zeros, and thereby does not clear all bytes in a block. Some SSDs may
1 do just that.
1
1 A FILE of ‘-’ denotes standard output. The intended use of this is
1 to shred a removed temporary file. For example:
1
1 i=$(mktemp)
1 exec 3<>"$i"
1 rm -- "$i"
1 echo "Hello, world" >&3
1 shred - >&3
1 exec 3>-
1
1 However, the command ‘shred - >file’ does not shred the contents of
1 FILE, since the shell truncates FILE before invoking ‘shred’. Use the
1 command ‘shred file’ or (if using a Bourne-compatible shell) the command
1 ‘shred - 1<>file’ instead.
1
1 An exit status of zero indicates success, and a nonzero value
1 indicates failure.
1