Date: Tue, 31 Oct 2006 09:03:58 -0800 (PST) From: Tim Clewlow <tim1timau@yahoo.com> To: freebsd-hackers@freebsd.org Subject: Re: [patch] rm can have undesired side-effects Message-ID: <20061031170358.94782.qmail@web50307.mail.yahoo.com> In-Reply-To: <20061031161640.71807.qmail@web53907.mail.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--- Daniel Valencia <fetrovsky@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@yahoo.com> > To: Bakul Shah <bakul@bitblocks.com>; Doug Barton > <dougb@FreeBSD.org> > Cc: delphij@FreeBSD.org; perryh@pluto.rain.com; > freebsd-hackers@freebsd.org > Sent: Monday, October 30, 2006 12:20:33 PM > Subject: Re: [patch] rm can have undesired > side-effects > > > --- Bakul Shah <bakul@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/)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061031170358.94782.qmail>