Date: Mon, 30 Oct 2006 18:05:31 +0800 From: LI Xin <delphij@delphij.net> To: Joerg Pernfuss <elessar@bsdforen.de> Cc: freebsd-hackers@freebsd.org, perryh@pluto.rain.com Subject: Re: [patch] rm can have undesired side-effects Message-ID: <4545CE6B.1010405@delphij.net> In-Reply-To: <20061030103212.13e6ad07@loki.starkstrom.lan> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <peterjeremy@optushome.com.au> 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 <inode_number> >=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 <delphij@delphij.net> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4545CE6B.1010405>