Date: Mon, 30 Oct 2006 10:50:44 -0800 From: Doug Barton <dougb@FreeBSD.org> To: Peter Jeremy <peterjeremy@optushome.com.au> Cc: freebsd-hackers@freebsd.org, perryh@pluto.rain.com, delphij@FreeBSD.org Subject: Re: [patch] rm can have undesired side-effects Message-ID: <45464984.1040602@FreeBSD.org> In-Reply-To: <20061030083849.GB871@turion.vk2pj.dyndns.org> References: <20061029222847.GA68272@marvin.astase.com> <20061030003628.42bc5f8d@loki.starkstrom.lan> <45455f6a.yNcc0kkyEKpoRv3m%perryh@pluto.rain.com> <20061030083849.GB871@turion.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45464984.1040602>