Date: Mon, 30 Oct 2006 10:32:12 +0100 From: Joerg Pernfuss <elessar@bsdforen.de> To: freebsd-hackers@freebsd.org Cc: perryh@pluto.rain.com Subject: Re: [patch] rm can have undesired side-effects 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>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <peterjeremy@optushome.com.au> 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 <inode_number> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061030103212.13e6ad07>