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

[James Youngman]

Interesting points, thanks!

Since shred cannot do anything useful with a symbolic link there are
only two (no, three) possible courses of action:

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 option (2) is inconsistent with the other things that shred
does; it scrambles things but (by default) doesn't delete them.

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").

So interpreting your point a bit freely, I guess you'd prefer this:

shred symlink: yields an error message; nothing is done

shred -u symlink: likewise

shred -f symlink: shreds the file the symlink points to

shred -u -f symlink: shreds the file the symlink points to, truncates
the file, but leaves the symlink alone (this is the current behaviour
we see without options)


This change is not by any means obvious; for example, it removes the
current protection that you get in this case:

~/tmp$ rm -f foo bar
~/tmp$ echo hello > foo
~/tmp$ ln -s foo bar
~/tmp$ chmod 400 foo
~/tmp$ ls -l foo bar
lrwxrwxrwx 1 james james 3 2008-09-20 15:25 bar -> foo
-r-------- 1 james james 6 2008-09-20 15:25 foo
~/tmp$ shred bar
shred: bar: failed to open for writing: Permission denied

... if we are using -f to tell shred to follow the symbolic link,
there is no extra option needed for "yes, really shred a read-only
file".

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.

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.

Thanks,
James.