Re: shred: bug or feature? think you should know about it

[Bob Proulx]

Thank you for you posting.  I have some questions and would like to
discuss this with you.

> when shred runs, the slack space is not wiped:

If you would be so kind as to educate this poor hacker.  What is
"slack" space?

> 0. # shred --version
> shred (fileutils) 4.1
> 1. # mkfs -t ext2 /dev/fd0
> 2. # dd if=/dev/zero of=/mnt/floppy/oooo ; sync ; /bin/rm /mnt/floppy/oooo ; 
> sync

This confuses me.  What is /mnt/floppy?  Is it a local directory or
has it been previously mounted?  I assume you droppd a mount command
after having run mkfs on a floppy.  I assume you mounted it between
steps 1 and 2?

I assume the dd stops when the output device fills up and returns an
error?  Thereby completely filling up the filesystem upon which
/mnt/floppy is mounted?  Just to zero everything, of course.  Now into
the core of the discussion.

> 3. # mount /mnt/floppy
> 4. # echo "good data" > /mnt/floppy/TEST

A file on the filesytem, presumably from the 'mkfs -t ext2 /dev/fd0'
above but without knowing the contents of your /etc/fstab this is
uncertain.  [And in fact the mount command would depend upon the OS
you are running on.  Likely this is linux since other systems would
actually require you to say what you were mounting where.]

> 5. # echo "evil data" | bmap --mode putslack /mnt/floppy/TEST

Now the real questions.  What is 'bmap'?  What is slackspace?  What
does bmap do to file TEST?

If I were to 'grep data /mnt/floppy/TEST' what would I see?

> 6. # strings /dev/fd0 | grep data
> good data
> evil data

So both strings are 'on the floppy' somewhere.  But not necessarily in
the file TEST.

> 7. # shred -u -v -z /mnt/floppy/TEST
> 8. # strings /dev/fd0 | grep data
> evil data

So likely 'evil data' is not actually stored in file TEST at all.  Or
at least it would have, should have, been shreded.  You showed it as
an ext2 filesystem which is a non-journalling filesytem.  There are
caveats in the documentation about shreds inneffectiveness when used
on a journalling filesystem.  [If I had been polled as to whether
shred should be included in utils I would have voted not since it is
too hard to get right.  Better to not include it at all.]

Since shred is only run on file TEST any data that is not stored in
file TEST could not reasonably be expected to be overwritten.  The
data here convinces me that bmap stores 'evil data' someplace other
than in the file TEST.  Since shred only works on the file TEST it
does not remove the evil data since it is elsewhere.  For that you
would have to shred wherever bmap stored that data.  Where is that?
What am I missing?

Bob