From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 30 10:06:54 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 491D616A47B for ; Mon, 30 Oct 2006 10:06:54 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F85E43D58 for ; Mon, 30 Oct 2006 10:06:21 +0000 (GMT) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id CCB3EEB0CFE; Mon, 30 Oct 2006 18:06:20 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id eiskp+KKDO5K; Mon, 30 Oct 2006 18:06:15 +0800 (CST) Received: from [10.217.12.47] (sina152-194.staff.sina.com.cn [61.135.152.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 3B196EB3459; Mon, 30 Oct 2006 18:06:13 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:x-enigmail-version:content-type; b=DMCACNPn/qNJ/CnnL0hSo8Xj78JHdV499Onn4QaHmfAuR9vxI5rrjJPrhRairw2i3 XH/RfpkT3Wwru4ZvLAuKA== Message-ID: <4545CE6B.1010405@delphij.net> Date: Mon, 30 Oct 2006 18:05:31 +0800 From: LI Xin Organization: The FreeBSD Project User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Joerg Pernfuss References: <20061029222847.GA68272@marvin.astase.com> <20061030003628.42bc5f8d@loki.starkstrom.lan> <45455f6a.yNcc0kkyEKpoRv3m%perryh@pluto.rain.com> <20061030083849.GB871@turion.vk2pj.dyndns.org> <20061030103212.13e6ad07@loki.starkstrom.lan> In-Reply-To: <20061030103212.13e6ad07@loki.starkstrom.lan> X-Enigmail-Version: 0.94.1.0 Content-Type: multipart/signed; micalg=pgp-ripemd160; protocol="application/pgp-signature"; boundary="------------enig9740C3C4138859AC6ED563A3" Cc: freebsd-hackers@freebsd.org, perryh@pluto.rain.com 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 10:06:54 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9740C3C4138859AC6ED563A3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Joerg Pernfuss wrote: > On Mon, 30 Oct 2006 19:38:49 +1100 > Peter Jeremy wrote: >=20 >> 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. >=20 > The only method I know of to find out all the hardlinks to a file is > find /path/to/mountpoint -type f -inum >=20 > The inode number can be obtained via `ls -li' if the file is linked, > or from the warning the committed patch issues. It surely isn't obvious= , > but neither is it virtually impossible, I'd say. >=20 > The intend of the patch boils down to: > - overwriting a file with multiple links suggets the user is > unaware of this > - if `rm -rP' is used and all links are under the hierarchy > that is to be deleted, the file will actually get overwritten > when the last link is removed > - if rm is not invoked recursive, print the inode number and > give the user the means to check out what is going on >=20 >> 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. >=20 > Now it gets tricky. Indeed, one can do this. > I wasn't aware of that. The second link is created with owner and acces= s > permissions of the first one and keeps them, even after the first file = is > deleted. So yes, Mallory can deny Alice the ability to remove her file,= > but she can't read it unless she can circumvent the unix file permissio= ns > system. >=20 > And Alice can search for the inode, link it again and dd(1) a fair shar= e > of /dev/random over it. Assuming that Alice's find(1) can enter the > directory in which Mallory linked the file. >=20 > That isn't really that nice, true. But why can i link files that I have= > no business with in the first place? Is there is specific reason? Another solution is that we follow the OpenBSD behavior and make it possible for the user to use the historical "feature=E2=80=9C, but by def= ault, if there is hard link then we just do nothing. Cheers, --=20 Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! --------------enig9740C3C4138859AC6ED563A3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFRc5rOfuToMruuMARA0qNAJ9qcaZinNX9qYdUg4ypN35PmL8XswCdEB0G uOOODatvvMhpyhtP4uX6yGg= =LxOG -----END PGP SIGNATURE----- --------------enig9740C3C4138859AC6ED563A3--