This is a discussion on Re: [patch] rm can have undesired side-effects - FreeBSD ; --- Daniel Valencia 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 ...
--- Daniel Valencia
> 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
> These are my 1.99 cents.
> - Daniel
> ----- Original Message ----
> From: Tim Clewlow
> To: Bakul Shah
; Doug Barton
> Cc: delphij@FreeBSD.org; firstname.lastname@example.org;
> Sent: Monday, October 30, 2006 12:20:33 PM
> Subject: Re: [patch] rm can have undesired
> --- Bakul Shah
> > 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
> > since
> > these commands can also unlink a file and once
> > unlinked in
> > this matter you can't scrub it. And also fix up
> > behavior
> > for -P when multiple links. And since mv can use
> > rename(2),
> > you will have to also dirty up the kernel
> > 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
> > 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
> > 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
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
- 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
Everyone is raving about the all-new Yahoo! Mail
email@example.com mailing list
To unsubscribe, send any mail to "firstname.lastname@example.org"