From owner-freebsd-stable@FreeBSD.ORG Wed Sep 26 20:42:00 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D17216A418 for ; Wed, 26 Sep 2007 20:42:00 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx01.syd.optusnet.com.au (fallbackmx01.syd.optusnet.com.au [211.29.132.93]) by mx1.freebsd.org (Postfix) with ESMTP id EC1F013C44B for ; Wed, 26 Sep 2007 20:41:59 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail11.syd.optusnet.com.au (mail11.syd.optusnet.com.au [211.29.132.192]) by fallbackmx01.syd.optusnet.com.au (8.12.11.20060308/8.12.11) with ESMTP id l8QE2TRH025982 for ; Thu, 27 Sep 2007 00:02:30 +1000 Received: from besplex.bde.org (c220-239-235-248.carlnfd3.nsw.optusnet.com.au [220.239.235.248]) by mail11.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id l8QE28Bl031218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Sep 2007 00:02:11 +1000 Date: Wed, 26 Sep 2007 23:56:37 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: d@delphij.net In-Reply-To: <46F953C4.1030707@delphij.net> Message-ID: <20070926235630.M7545@besplex.bde.org> References: <200709251743.l8PHhvlP012244@lurza.secnetix.de> <46F953C4.1030707@delphij.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: torfinn.ingolfsen@broadpark.no, freebsd-stable@freebsd.org Subject: Re: rm(1) bug, possibly serious X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2007 20:42:00 -0000 On Tue, 25 Sep 2007, LI Xin wrote: > I think this is a bug, here is a fix obtained from NetBSD. This bug, if any, cannot be fixed in rm. > The reasoning (from NetBSD's rm.c,v 1.16): Bugs can easily be added to rm. > Strip trailing slashes of operands in checkdot(). > > POSIX.2 requires that if "." or ".." are specified as the basename > portion of an operand, a diagnostic message be written to standard > error, etc. Note that POSIX only requires this for the rm utility. (See my previous mail about why this is bogus.) Pathname resolution and a similarly bogus restriction on rmdir(2) requires some operations with dot or dot-dot to fail, and any utility that uses these operations should then print a diagnostic, etc. > We strip the slashes because POSIX.2 defines basename > as the final portion of a pathname after trailing slashes have been > removed. POSIX says "the basename portion of the operand (that is, the final pathname component". This doesn't mean the operand mangled by basename(3). > This also makes rm "perform actions equivalent to" the POSIX.1 > rmdir() and unlink() functions when removing directories and files, > even when they do not follow POSIX.1's pathname resolution semantics > (which require trailing slashes be ignored). Which POSIX.1? POSIX.1-2001 actually requires "trailing slashes shall be resolved as if a single dot character were appended to the pathname". This is completely different from removing the slash: rm / # ENOTDIR rm # success unless ENOENT etc. rm / # success... rm # EISDIR rm / # ENOTDIR rm # success (removes symlink) rm / # EISDIR rm # success (removes symlink) rmdir ... # reverse most of above Anyway, mangling the operands makes the utilities perform actions different from the functions. The problem case is "rm -r /" which asks for removing the directory pointed to by the symlink and all its contents, and is useful -- you type the trailing symlink if you want to ensure that the removal is as recursive as possible. With breakage of rmdir(2) to POSIX spec, this gives removal the contents of the directory pointed to be the symlink and then fails to remove the directory. With breakage as in NetBSD, this gives removal of the symlink only. > If nobody complains about this I will request for commit approval from re@. ++ Bruce