From owner-freebsd-bugs@FreeBSD.ORG Sun Apr 1 19:30:18 2012 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23C1E106564A for ; Sun, 1 Apr 2012 19:30:18 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E9EC98FC12 for ; Sun, 1 Apr 2012 19:30:17 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q31JUHgJ038560 for ; Sun, 1 Apr 2012 19:30:17 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q31JUHLE038557; Sun, 1 Apr 2012 19:30:17 GMT (envelope-from gnats) Date: Sun, 1 Apr 2012 19:30:17 GMT Message-Id: <201204011930.q31JUHLE038557@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Matthew Story Cc: Subject: Re: bin/166553: find -delete documentation is misleading X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthew Story List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2012 19:30:18 -0000 The following reply was made to PR bin/166553; it has been noted by GNATS. From: Matthew Story To: Richard Kettlewell Cc: freebsd-gnats-submit@freebsd.org Subject: Re: bin/166553: find -delete documentation is misleading Date: Sun, 1 Apr 2012 15:25:00 -0400 On Sun, Apr 1, 2012 at 1:25 PM, Richard Kettlewell wr= ote: > On 01/04/2012 18:24, Matthew Story wrote: >> >> On Sun, Apr 1, 2012 at 5:24 AM, Richard Kettlewell >> =A0wrote: >>> >>> >>> The documentation for 'find -delete' includes the following remark: >>> >>> =A0 =A0It will not attempt to delete a filename with a =93/=94 characte= r in its >>> pathname relative to =93.=94 for security reasons. >>> >>> This reflects a defensive test early in f_delete. However, the test wil= l >>> not succeed, since find does not use FTS_NOCHDIR, so entry->fts_accpath >>> should never contain "/". >> >> >> $ # show test succeeds >> $ mkdir -p foo/bar/baz >> $ find ./foo -delete >> find: -delete: ./foo: relative path potentially not safe >> >> The reason that fts_accpath contains a leading ``./'' in this case is >> that fts, even without FTS_NOCHDIR, does not chdir into the parent >> directory of depth 0 directories on the first pass, fts_accpath will >> always equal fts_pathname on depth 0 FTSENTs. > > > Light dawns l-) > > Still, the wording could be improved: it doesn't really describe well whe= n > -delete will succeed and when it won't. Yes, the wording is confusing, and it's not actually a correct assessment of what the code is doing ... it also doesn't note that this condition is fatal: $ # show that an absolute path also triggers the condition $ ./find /usr/home/user1/foo -depth 0 -delete find: -delete: /usr/home/user1/foo: relative path potentially not safe $ echo $? 1 The code here is actually just fatalling out if FTSENT->fts_accpath contains a ``/'', wether or not it is preceded by a ``.'' There is an additional misleading comment in the code to the same end as the manage. /* Potentially unsafe - do not accept relative paths whatsoever */ > > ttfn/rjk --=20 regards, matt