Re: Shred and symbolic links. People use it like a safer "rm" and get...

[Bob Proulx]

James Youngman wrote:
> 1. Dereference the link; shred the thing it points to.
> 2. Unlink the symbolic link
> 3. Refuse to do anything
> 
> At the moment then, shred does (1).  shred -u shreds the file and then
> truncates it.   The -f option is not needed.

I think that shred is fundamentally a different thing than rm.  rm
simply removes a file from a directory.  It doesn't actually do
anything with the disk space.  The filesystem garbage collects it if
there are no other pointers to it.  Whereas shred actively tries to
make the indicate files unrecoverable.  rm doesn't try to make it
impossible to get to the file again.

Consider this:

  mkdir a b
  date -R > a/file1
  ln a/file1 b/file2

At that point both files are linked together.  Either may be removed
and the other will remain.

  rm a/file1
  cat b/file2

  ln b/file2 a/file1
  rm b/file2
  cat a/file1

So rm is not about file contents.  There is no believe that removing
the file is making it inaccessible.  It is just gone from the
directory from which it is being removed.  rm does not affect file
contents.  rm simply removes the file from the directory.

But what about truncation?

  ln b/file2 a/file1
  : > b/file2
  cat a/file1

It is gone.  Truncation affects the contents of the file.  shred
affects file contents in the same way that truncation affects file
contents.  In which case it should follow the symlink.  Symlinks
should be transparent.

It seems that it would be okay to have an option to avoid tracking
symlinks though.  But that shouldn't be the default paradigm.

It seems to me that if someone is wanting to shred the file then they
want the contents to be unrecoverable.  In which case it should follow
symlinks transparently.

  editor afile
  ...I don't want that information to be available...
  shred afile
  ...That private information is gone forever...

Consider what happens in this case then:

  touch bfile
  ln -s bfile afile
  editor afile
  ...I don't want that information to be available...
  shred afile
  ...That private information is gone forever...
  cat bfile
  ...But I used shred on that file!

I think conceptually the use of shred is on information not files.
This differentiates it from rm which conceptually simply operates on
files in a single directory.

> I think option (2) is inconsistent with the other things that shred
> does; it scrambles things but (by default) doesn't delete them.

Agreed.

> The principle of operation of shred(1) is that it is not reversible.
> I always look extra carefully at stuff I'm putting in the shredder, to
> make sure that really nobody needs it.    It might be reasonable to
> require shred to refuse to do anything with a symbolic link unless the
> -f option is given.  The rationale for this would essentially be that
> the cost of a mistake on the part of the user is huge, and (so the
> argument would go) this potentially changes the balance between "trust
> the user" and "protect the user".  (Being Unix-y, coreutils goes in
> mainly for "trust the user").

Being a new command I doubt there is a long legacy of shred use with
regards to symlinks.  So nothing serious to break with behavior
changes.  And I don't feel strongly about shred.

But I think creating special cases where particular commands behave
different with regards to symlinks that is expected or differently
from the main set of commands is a bad trend.  Consistency is more
important.

> Personally, I think that the loss of this last protection is worse
> than the protective effect of not following symbolic links by default.
>  So if these are the only possible options, I would prefer to leave
> things as they are.

Agreed.

> An alternative would be to add -P and -L options, but the current
> default is like -L, so this change also would not be without problems.

Since I expressed an opinion already I will do so here too.
I don't feel strongly about adding special options to do special
things.

Bob