From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 30 18:51:08 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 BE0AC16A403 for ; Mon, 30 Oct 2006 18:51:08 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.FreeBSD.org (Postfix) with SMTP id 17F0243DB5 for ; Mon, 30 Oct 2006 18:50:47 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 21719 invoked by uid 399); 30 Oct 2006 18:50:46 -0000 Received: from localhost (HELO ?192.168.0.7?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 30 Oct 2006 18:50:46 -0000 Message-ID: <45464984.1040602@FreeBSD.org> Date: Mon, 30 Oct 2006 10:50:44 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Peter Jeremy References: <20061029222847.GA68272@marvin.astase.com> <20061030003628.42bc5f8d@loki.starkstrom.lan> <45455f6a.yNcc0kkyEKpoRv3m%perryh@pluto.rain.com> <20061030083849.GB871@turion.vk2pj.dyndns.org> In-Reply-To: <20061030083849.GB871@turion.vk2pj.dyndns.org> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, perryh@pluto.rain.com, delphij@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 18:51:08 -0000 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