From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 30 09:32:28 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 DBEE916A40F for ; Mon, 30 Oct 2006 09:32:27 +0000 (UTC) (envelope-from elessar@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id 39B9943D45 for ; Mon, 30 Oct 2006 09:32:27 +0000 (GMT) (envelope-from elessar@bsdforen.de) Received: from localhost (mail [127.0.0.12]) by mail.bsdforen.de (Postfix) with ESMTP id 4B3F54241C8; Mon, 30 Oct 2006 10:32:26 +0100 (CET) X-Virus-Scanned: amavisd-new at bsdforen.de Received: from mail.bsdforen.de ([127.0.0.12]) by localhost (mail.bsdforen.de [127.0.0.12]) (amavisd-new, port 10024) with ESMTP id oQIwgjnPFFLt; Mon, 30 Oct 2006 10:32:25 +0100 (CET) Received: from loki.starkstrom.lan (p549CE7DE.dip.t-dialin.net [84.156.231.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id 71779423DE4; Mon, 30 Oct 2006 10:32:17 +0100 (CET) Date: Mon, 30 Oct 2006 10:32:12 +0100 From: Joerg Pernfuss To: freebsd-hackers@freebsd.org Message-ID: <20061030103212.13e6ad07@loki.starkstrom.lan> 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> X-Mailer: Sylpheed-Claws 2.2.3 (GTK+ 2.8.20; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: multipart/signed; boundary=Sig_U1hr9CC.N7f7gSDIFarMWJ4; protocol="application/pgp-signature"; micalg=PGP-SHA1 Cc: 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 09:32:28 -0000 --Sig_U1hr9CC.N7f7gSDIFarMWJ4 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 30 Oct 2006 19:38:49 +1100 Peter Jeremy wrote: > 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. The only method I know of to find out all the hardlinks to a file is find /path/to/mountpoint -type f -inum 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. 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 > 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. Now it gets tricky. Indeed, one can do this. I wasn't aware of that. The second link is created with owner and access 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 permissions system. And Alice can search for the inode, link it again and dd(1) a fair share of /dev/random over it. Assuming that Alice's find(1) can enter the directory in which Mallory linked the file. 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? Joerg --=20 | /"\ ASCII ribbon | GnuPG Key ID | e86d b753 3deb e749 6c3a | | \ / campaign against | 0xbbcaad24 | 5706 1f7d 6cfd bbca ad24 | | X HTML in email | .the next sentence is true. | | / \ and news | .the previous sentence was a lie. | --Sig_U1hr9CC.N7f7gSDIFarMWJ4 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQFFRcacH31s/bvKrSQRAl4qAJ9Y863TR/BLPyw3oUUszx0jwJo7NACfR1Lm 4q1zN+OG+pNDNkYr1NjiTfY= =D4IW -----END PGP SIGNATURE----- --Sig_U1hr9CC.N7f7gSDIFarMWJ4--