From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 31 17:04:10 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0213B16A403 for ; Tue, 31 Oct 2006 17:04:10 +0000 (UTC) (envelope-from tim1timau@yahoo.com) Received: from web50307.mail.yahoo.com (web50307.mail.yahoo.com [206.190.38.61]) by mx1.FreeBSD.org (Postfix) with SMTP id 8749843D69 for ; Tue, 31 Oct 2006 17:03:59 +0000 (GMT) (envelope-from tim1timau@yahoo.com) Received: (qmail 94784 invoked by uid 60001); 31 Oct 2006 17:03:58 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=DVGC686sKA6K/uYnkxp7qdSCFAJ9M1viGXUXCrkKG5+wNJpwdqXN5SHaSugkLgmvdUEo+DsHNyFHmP23ola8WseKq+sywk7hgkRuZKbt6cWEhSCIOUdltw+koe28iuh5Yz3geta+G0KkrNQP4ulzj8ei+FqCxtgAWO82nuIVkhs= ; Message-ID: <20061031170358.94782.qmail@web50307.mail.yahoo.com> Received: from [210.0.100.149] by web50307.mail.yahoo.com via HTTP; Tue, 31 Oct 2006 09:03:58 PST Date: Tue, 31 Oct 2006 09:03:58 -0800 (PST) From: Tim Clewlow To: freebsd-hackers@freebsd.org In-Reply-To: <20061031161640.71807.qmail@web53907.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [patch] rm can have undesired side-effects X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2006 17:04:10 -0000 --- 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 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 > To: Bakul Shah ; Doug Barton > > 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 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/)