From nobody@FreeBSD.org  Sun Apr  1 09:24:27 2012
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 63BD7106564A
	for <freebsd-gnats-submit@FreeBSD.org>; Sun,  1 Apr 2012 09:24:27 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22])
	by mx1.freebsd.org (Postfix) with ESMTP id 4F2148FC15
	for <freebsd-gnats-submit@FreeBSD.org>; Sun,  1 Apr 2012 09:24:27 +0000 (UTC)
Received: from red.freebsd.org (localhost [127.0.0.1])
	by red.freebsd.org (8.14.4/8.14.4) with ESMTP id q319OQT5036770
	for <freebsd-gnats-submit@FreeBSD.org>; Sun, 1 Apr 2012 09:24:26 GMT
	(envelope-from nobody@red.freebsd.org)
Received: (from nobody@localhost)
	by red.freebsd.org (8.14.4/8.14.4/Submit) id q319OQeN036749;
	Sun, 1 Apr 2012 09:24:26 GMT
	(envelope-from nobody)
Message-Id: <201204010924.q319OQeN036749@red.freebsd.org>
Date: Sun, 1 Apr 2012 09:24:26 GMT
From: Richard Kettlewell <rjk@greenend.org.uk>
To: freebsd-gnats-submit@FreeBSD.org
Subject: find -delete documentation is misleading
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         166553
>Category:       docs
>Synopsis:       find(1): find -delete documentation is misleading
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-doc
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          doc-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Apr 01 09:30:12 UTC 2012
>Closed-Date:    
>Last-Modified:  Sun Mar  2 22:40:00 UTC 2014
>Originator:     Richard Kettlewell
>Release:        
>Organization:
>Environment:
>Description:
The documentation for 'find -delete' includes the following remark:

    It will not attempt to delete a filename with a / character in its pathname relative to . for security reasons. 

This reflects a defensive test early in f_delete. However, the test will not succeed, since find does not use FTS_NOCHDIR, so entry->fts_accpath should never contain "/".

I suggest that this remark be deleted from the man page.

>How-To-Repeat:

>Fix:


>Release-Note:
>Audit-Trail:

From: Matthew Story <matthewstory@gmail.com>
To: Richard Kettlewell <rjk@greenend.org.uk>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: bin/166553: find -delete documentation is misleading
Date: Sun, 1 Apr 2012 13:24:03 -0400

 On Sun, Apr 1, 2012 at 5:24 AM, Richard Kettlewell <rjk@greenend.org.uk> wr=
 ote:
 >
 > The documentation for 'find -delete' includes the following remark:
 >
 > =A0 =A0It will not attempt to delete a filename with a =93/=94 character =
 in its pathname relative to =93.=94 for security reasons.
 >
 > This reflects a defensive test early in f_delete. However, the test will =
 not succeed, since find does not use FTS_NOCHDIR, so entry->fts_accpath sho=
 uld 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.
 
 regards,
 matt

From: Richard Kettlewell <rjk@greenend.org.uk>
To: Matthew Story <matthewstory@gmail.com>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: bin/166553: find -delete documentation is misleading
Date: Sun, 01 Apr 2012 18:25:55 +0100

 > 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 
 when -delete will succeed and when it won't.
 
 ttfn/rjk

From: Matthew Story <matthewstory@gmail.com>
To: Richard Kettlewell <rjk@greenend.org.uk>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: bin/166553: find -delete documentation is misleading
Date: Sun, 1 Apr 2012 15:25:00 -0400

 > Still, the wording could be improved: it doesn't really describe well when
 > -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 */
 
 --=20
 regards,
 matt
Responsible-Changed-From-To: freebsd-bugs->freebsd-doc 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Mon Apr 2 06:23:23 UTC 2012 
Responsible-Changed-Why:  
reclassify. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=166553 

From: Jim Riggs <ports@christianserving.org>
To: bug-followup@FreeBSD.org,
 rjk@greenend.org.uk
Cc:  
Subject: Re: docs/166553: find(1): find -delete documentation is misleading
Date: Tue, 24 Apr 2012 14:57:37 -0500

 I'm not sure that I would classify this as a documentation bug. It seems =
 to be a code bug unless the documentation is just completely unclear as =
 to how this is to behave. It seems that the intent is that you can't use =
 -delete with ./ or ../ in the path; however, it completely blocks =
 anything with / anywhere in the path. For example, this will fail (see =
 bin/48271):
 
 # cd /
 # mkdir testdir
 # mkdir testdir/testdir2
 # find /testdir -delete
 find: -delete: /testdir: relative path potentially not safe
 
 Now, what is "relative" in the path '/testdir'? So, the question is, =
 what is the code trying to stop? Is there a security issue with an =
 _absolute_ path, a _relative_ path, or both? Right now, it is blocking =
 both. Is -delete only supposed to be used in cwd (i.e. '.')? If so, why =
 the restriction? I am just trying to understand what is "potentially not =
 safe."
 
 This issue is also hosing my `make release' on 9.0-RELEASE with =
 WITHOUT_GAMES defined in src.conf:
 
 ...
 
 install -o root -g wheel -m 444  =
 /usr/src/etc/../sys/amd64/conf/GENERIC.hints  =
 /usr/obj/release/dist/base/boot/device.hints
 find //usr/obj/release/dist/doc -empty -delete
 find //usr/obj/release/dist/games -empty -delete
 find: -delete: //usr/obj/release/dist/games: relative path potentially =
 not safe
 *** Error code 1
 
 Stop in /usr/src.
 *** Error code 1
 
 Stop in /usr/src.
 *** Error code 1
 
 Stop in /usr/src/release.
 *** Error code 1
 
 Stop in /usr/src/release.
 

From: Jilles Tjoelker <jilles@stack.nl>
To: bug-followup@FreeBSD.org, rjk@greenend.org.uk
Cc: Matthew Story <matthewstory@gmail.com>
Subject: Re: docs/166553: find(1): find -delete documentation is misleading
Date: Sun, 2 Mar 2014 23:38:25 +0100

 In PR docs/166553, Richard Kettlewell wrote:
 > The documentation for 'find -delete' includes the following remark:
 
 > It will not attempt to delete a filename with a "/" character in its
 > pathname relative to "." for security reasons.
 
 > This reflects a defensive test early in f_delete. However, the test
 > will not succeed, since find does not use FTS_NOCHDIR, so
 > entry->fts_accpath should never contain "/".
 
 > I suggest that this remark be deleted from the man page.
 
 In SVN r246628 and r253886 (both are in 10.0-RELEASE), I removed the two
 most common causes for the confusing error message about relative
 pathnames: if "." cannot be opened (except if find(1)'s own open
 succeeds but fts(3)'s open fails) and if an attempt is made to delete a
 pathname given as operand to find(1). The former now gives a clear error
 message and the latter is now allowed.
 
 -- 
 Jilles Tjoelker
>Unformatted:
