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