Date: Sun, 5 Nov 2006 05:28:32 +0100 From: Joerg Pernfuss <elessar@bsdforen.de> To: <freebsd-hackers@freebsd.org> Subject: Re: [patch] rm can have undesired side-effects Message-ID: <20061105052832.68400a56@loki.starkstrom.lan> In-Reply-To: <200611050222.kA52Mdm0011497@apollo.backplane.com> References: <20061029222847.GA68272@marvin.astase.com> <20061030003628.42bc5f8d@loki.starkstrom.lan> <00f201c6fbb6$0c6bd150$b3db87d4@multiplay.co.uk> <20061030024358.39a12359@loki.starkstrom.lan> <200611050222.kA52Mdm0011497@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_i8/aBOQpG+geYAE2sQ26qdq Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sat, 4 Nov 2006 18:22:39 -0800 (PST) Matthew Dillon <dillon@apollo.backplane.com> wrote: > : I agree. I will make this change in DragonFly right now, in > : fact. The -P option really needs to be consistent across > : environments and my take on the original design was so users could > : alias rm to rm -P in their .cshrc files. Clearly it cannot destroy > : the contents of the file in the presence of hard links when used in > : that context. > : > : -Matt >=20 > Followup note here. OpenBSD's /bin/rm source is doing something > unexpected... it isn't unlink()ing the file if it has > 1 > hardlinks and -P is used. That is its current behavior. Yes, delphij@ and I stumbled upon that as well. It isn't really reflected in the man page and the initial OpenBSD commit log "Attempt to do something reasonable when overwrite mode is combined with hard links, and document it. In consultation with dynamo and approved by millert." isn't that conclusive either. With the objection that was raised around here, maybe it was done intentionally. > I'm not sure I agree with this. It makes -P unusable as a .cshrc > alias. I would have expected it to still unlink the file. Yes, this behaviour breaks `rm -r' when rm is aliased to rm -P, which limits the usefulness of the -P flags significantly imho. But it makes sure one does not miss the warning. Just hope for good error handling in the script. > In anycase, for now I am going to sync DragonFly's rm with > OpenBSD anyhow, even though I'm scratching my head a bit. This may > be just as broken as before, just in a different (and safer) way. So far the easiest mayhem one could cause (aside from safekeeping someone elses file) I could think of is in a quota environment. If Mallory links all of Alice's files, then Alice's quota will fill up, because she probably can't delete her files anymore. Yet as they preserve owner and access mode, they will count towards Alice's limit I would assume. Quotas are set on a per-filesystem, not per-path basis (according to quotactl(2), not tested). If Mallory set up the directory in which the files got linked just as bad as Alice set up her ~/, then Alice can either delete the malicious links (write access to the directory), link them back (execute access to the directory) or watch them sit there (read access to the directory). In the first case, everything is good. In the second one, she can at least dd(1) the file and destroy the data, although the quota will fill. In the third, Alice can try to somehow magically write directly to that inode - no idea. But the quota will fill up. And I still have no idea why ln(1) allows links to files the user has no access rights whatsoever, in a directory the owner of the file has no access to in the first place. And what happens when I link the 0600 file state_secret.doc that is owned by someone else, into a directory I own and set SUIDDIR? Will that then be my file and the original owner will be denied access on his link to the file? (yes, kernel support required, i know. but it would be fun.) I am not convinced anymore that rm is the real culprit. 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_i8/aBOQpG+geYAE2sQ26qdq Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD4DBQFFTWhwH31s/bvKrSQRAvfrAJ91Y+BcscNGdG3YQUdQf4LwknCx+gCYpLxC 1Rd2hXk+4JUyiymKtGriBA== =ReX1 -----END PGP SIGNATURE----- --Sig_i8/aBOQpG+geYAE2sQ26qdq--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061105052832.68400a56>