[patch] rm can have undesired side-effects

[Tim Clewlow]

--- Daniel Valencia <fetrovsky at yahoo.com> wrote:

> Actually, I would like to support this motion...
> Thinking over the possible behaviours of -P is to
> sit in a room saying "to delete or not to delete..."
>  If you think it over from a higher perspective,
> "The UNIX Way" (TM) is to have individual commands
> for specific tasks and to extract tasks from
> commands that have gotten too complex... and I think
> this is the case of rm...  a "shred" command should
> be added that has the following behaviour:
> 
> if the file is not writable, return with error.
> if the file has multiple links, and option -f was
> not specified, return with error.
> overwrite the file.
> optionally, unlink the file.
> 
> Additionally, -P should either be rm'ed from rm, or
> added as a backwards compatibility hack that calls
> "shred" and returns with error every time the latter
> does.
> 
> These are my 1.99 cents.
> 
> 
> - Daniel
> 
> 
> ----- Original Message ----
> From: Tim Clewlow <tim1timau at yahoo.com>
> To: Bakul Shah <bakul at bitblocks.com>; Doug Barton
> <dougb at FreeBSD.org>
> Cc: delphij at FreeBSD.org; perryh at pluto.rain.com;
> freebsd-hackers at freebsd.org
> Sent: Monday, October 30, 2006 12:20:33 PM
> Subject: Re: [patch] rm can have undesired
> side-effects
> 
> 
> --- Bakul Shah <bakul at bitblocks.com> wrote:
> 
> > Sorry if I tuned in late:-)
> > 
> > I vote for taking *out* -P.  It is an ill-designed
> > feature.
> > Or if you keep it, also add it to mv, cp -f & ln
> -f
> > since
> > these commands can also unlink a file and once
> > unlinked in
> > this matter you can't scrub it.  And also fix up
> the
> > behavior
> > for -P when multiple links.  And since mv can use
> > rename(2),
> > you will have to also dirty up the kernel
> interface
> > somehow.
> > Not to mention even editing such a sensitive file
> > can leave
> > stuff all over the disk that a bad guy can get at.
> 
> > If you
> > are truely paranoid (as opposed to paranoid only
> > when on
> > meds) you know how bad that is!
> > 
> > If you are that concious about scrubbing why not
> add
> > scrubbing as a mount option (suggested option: -o
> > paranoid)
> > then at least it will be handled consistently.
> > 
> > What's the world come to when even the paranoid
> are
> > such
> > amateurs.
> > 
> > -- bakul
> > 
> 
> Based on all the potential situations where a -P
> option may possibly be implemented, is it worthwhile
> considering creating a command that just scrubs a
> file, and does nothing else. This would seem to fit
> the Unix paradigm of single command to do a single
> thing, and may be preferable to attempting to embed
> this function in every command that may "possibly"
> remove a file.
> 
> Just my 2c
> 
> Tim
> 

Having thought this over some more, if a
shred/scramble/scrub command is created in its own
right, then a number of new features could be added
that do not currently exist.

- The command could be writen to protect a single
file, or, it could also write to an entire file
system/media.

- The command could offer many types of randomising
possiblities, eg the current 0xff, 0x00, 0xff; or
perhaps /dev/random could be written; or perhaps the
user could specify exactly what is to be used to
overwrite the file/file system - from memory some
large organistations (govt depts) have specific rules
about how files/file systems should be overwritten
before old medie is thrown out and replaced (so no-one
can scavenge the media and read sensitive data)

Kind of thinking out loud here, apologies if its
noisy, Tim.



 
____________________________________________________________________________________
Everyone is raving about the all-new Yahoo! Mail 
(http://advision.webevents.yahoo.com/mailbeta/)