Date: Tue, 02 Oct 2007 09:22:58 +1000 From: Mark Andrews <Mark_Andrews@isc.org> To: Ian Smith <smithi@nimnet.asn.au> Cc: freebsd-stable@freebsd.org, LI Xin <d@delphij.net> Subject: Re: rm(1) bug, possibly serious Message-ID: <200710012322.l91NMw6l078435@drugs.dv.isc.org> In-Reply-To: Your message of "Mon, 01 Oct 2007 14:37:39 %2B1000." <Pine.BSF.3.96.1071001142356.13846D-100000@gaia.nimnet.asn.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Thu, 27 Sep 2007, Mark Andrews wrote: > (I wrote:) > > > On Tue, 25 Sep 2007, LI Xin wrote: > > > > Oliver Fromme wrote: > > > > > Nicolas Rachinsky wrote: > > > > > > Oliver Fromme wrote: > > > > > > > By the way, an additional confusion is that ".." and "../" > > > > > > > are handled differently. Specifying ".." always leads to > > > > > > > this message: > > > > > > > > > > > > > > rm: "." and ".." may not be removed > > > > > > > > > > > > > > and nothing is actually removed. It is confusing that > > > > > > > adding a slash leads to a different error message _and_ > > > > > > > removal of the contents of the parent directory. Clearly > > > > > > > a POLA violation. > > > > > > Clearly a bug, and well spotted, especially if as old as reported. > > > > > > > > > > > > > > > Adding a slash often leads to different behaviour. > > > > > > > > > > Yes, I'm aware of that. I often make use of the feature > > > > > that "find /sys/" expands the symlink, while "find /sys" > > > > > does not. The same holds true for ls(1). > > > > > > But fortunately not for rm(1): > > > > > > The rm utility removes symbolic links, not the files referenced by > the > > > links. > > > > > > It is an error to attempt to remove the files /, . or .. > > > > > > > > However, I would still argue that there is no sane reason > > > > > for "rm -rf ../" behaving differently from "rm -rf ..", > > > > > especially because it behaves differently in a destructive > > > > > way. That's why I call it a POLA violation. > > > > > > > > Also a POSIX violation IMHO :-) > > > > > > Indeed; I can't imagine a situation where removing "." (let alone "..") > > > and so orphaning the pwd might be considered sane, never mind legal .. > > > but maybe I lack imagination :) > > > > You lack imagination. > > No doubt :) > > > When you found the directory you want to remove and you are > > in it it is much less error prone to remove "." recursively > > that to go up one directory and try to find the directory > > you were just in. > > Sorry, I can't agree. I take comfort in knowing that 'rm .' will fail, > that 'rm *' will not remove '.' (let alone '..'!), and that rm will not > orphan the pwd. Neither will umount, for that matter .. You asked to be shown a example. It's a perfectly reasonable example. > > The the prohibitions comes from when you literally removed > > directories by unlinking the directory and "." and ".." > > within the directory in user space. It was easy to stuff > > up a directory structure. > > Regardless of how implemented in the filesystem, having the pwd become > invalid isn't something I ever expect to happen, and I'll continue to > rely on: 'It is an error to attempt to remove the files /, . or ..' It's something that you need to expect on a multi-process system. It happens to me one or twice a month. Mark > Cheers, Ian -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200710012322.l91NMw6l078435>