From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 30 19:16:16 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 7EBAC16A412; Mon, 30 Oct 2006 19:16:16 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (bitblocks.com [209.204.185.216]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB8D743D45; Mon, 30 Oct 2006 19:16:11 +0000 (GMT) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (localhost.bitblocks.com [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id 06DFF5B82; Mon, 30 Oct 2006 11:16:11 -0800 (PST) To: Doug Barton In-reply-to: Your message of "Mon, 30 Oct 2006 10:50:44 PST." <45464984.1040602@FreeBSD.org> Date: Mon, 30 Oct 2006 11:16:10 -0800 From: Bakul Shah Message-Id: <20061030191611.06DFF5B82@mail.bitblocks.com> Cc: perryh@pluto.rain.com, delphij@FreeBSD.org, freebsd-hackers@freebsd.org 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: Mon, 30 Oct 2006 19:16:16 -0000 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 Doug Barton writes: > Peter Jeremy wrote: > > On Sun, 2006-Oct-29 18:11:54 -0800, perryh@pluto.rain.com wrote: > >> I think a very strong case can be made that the *intent* of -P -- > >> to prevent retrieval of the contents by reading the filesystem's > >> free space -- implies that it should affect only the "real" removal > >> of the file, when its blocks are released because the link count > >> has become zero. > > ... > >> In this interpretation, "rm -P" when the link count exceeds 1 is > >> an erroneous command. > > > > I agree. Doing "rm -P" on a file with multiple links suggests that > > the user is unaware that there are multiple links. I don't think > > that just unlinking the file and issuing a warning is a good solution > > because it's then virtually impossible to locate the other copy(s) > > of the file, which remains viewable. I believe this is a security > > hole. > > > > Consider: In FreeBSD, it is possible to create a hardlink to a file if > > you are not the owner, even if you can't read it. Mallory may decide > > to create hardlinks to Alice's files, even if he can't read them today > > on the off-chance that he may be able to circumvent the protections at > > a later date. Unless Alice notices that her file has a second link > > before she deletes it, when she issues "rm -P", she will lose her link > > to the file (and her only way of uniquely identifying it) whilst > > leaving the remaining link to the file in Mallory's control. > > I think Peter is right here. I recently patched the -P option to error > out if a file is unwritable. I think that is the correct behavior here > too. If the file is not removed, then it is correct for rm to exit > with an rc > 0. Another poster mentioned the case of using rm in a > script, or for a large directory where this kind of warning might get > missed, which is one of the reasons I think it needs to exit with an > error code. > > My suggestion would be to change warnx() to errx(), and drop the > return(1); from that patch. If there are no objections I'll do it > myself if no one gets to it first. > > In any case I think that this is a good addition to the code, and I'm > glad that this issue was raised. > > Doug > > -- > > This .signature sanitized for your protection > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"