From nobody@FreeBSD.org  Tue Mar 13 19:08:15 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 74C69106566B
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 13 Mar 2012 19:08:15 +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 599FA8FC16
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 13 Mar 2012 19:08:15 +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 q2DJ8FlH030909
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 13 Mar 2012 19:08:15 GMT
	(envelope-from nobody@red.freebsd.org)
Received: (from nobody@localhost)
	by red.freebsd.org (8.14.4/8.14.4/Submit) id q2DJ8F9G030908;
	Tue, 13 Mar 2012 19:08:15 GMT
	(envelope-from nobody)
Message-Id: <201203131908.q2DJ8F9G030908@red.freebsd.org>
Date: Tue, 13 Mar 2012 19:08:15 GMT
From: Matthew Story <matthewstory@gmail.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: [patch][bin] find fails with .: permission denied, even when using absolute paths
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         166056
>Category:       bin
>Synopsis:       [patch][bin] find(1) fails with .: permission denied, even when using absolute paths
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Mar 13 19:10:03 UTC 2012
>Closed-Date:    
>Last-Modified:  Wed Mar 14 22:14:00 UTC 2012
>Originator:     Matthew Story
>Release:        8.2
>Organization:
>Environment:
FreeBSD axe0.blackskyresearch.net 8.2-RELEASE-p2 FreeBSD 8.2-RELEASE-p2 #0: Sun Jul  3 00:57:18 EDT 2011     root@osprey.blackskyresearch.net:/usr/obj/usr/src/sys/blackskyresearch-amd64-8-2-20110702  amd64
>Description:
When executing find on an absolute path (or many absolute path), find fatally errors if it cannot open ".".  This is particularly problematic when running find (or programs that exec find) from cron as an underprivileged user.

I can not find any reference to cwd in the POSIX 2008 specification for find, so it likely seems that this is not a violation of the specification, but it is also unnecessary.  The only reason for opening "." is for the -exec primative to fork&exec in cwd of the bounding process, due to chdir calls in fts_set.  If we set the FTS_NOCHDIR flag if we cannot open "." the need to chdir prior to -exec is removed.

Alex Ginzburg <alex at SPAMFREE tablethotels.com> originally discovered this behavior, so if the solution is picked up (or resolved in another way) he should be credited in the Reported By.
>How-To-Repeat:
From shell

$ su -
# install -d -m 700 testfind
# cd testfind
# su notroot
$ find /usr/src/usr.bin/find
find: .: Permission denied 

Or from cron (original discovery case):

*  *   *   *   *   notroot find /usr/src/usr.bin/find # ...

The workaround we have been using is to always cd to a safe place before running find, or a script that makes use of find ...
>Fix:
apply patch (patch was made against -CURRENT).  patch will warn if it cannot open ".", and set the FTL_NOCHDIR flag before proceeding, below cases demonstrate functionality with&without the -exec flag

$ su -
# install -d -m 700 testfind
# cd testfind
# su notroot
$ # without exec flag
$ find /usr/src/usr.bin/find
find: .: Permission denied
/usr/src/usr.bin/find
/usr/src/usr.bin/find/extern.h
/usr/src/usr.bin/find/find.c
/usr/src/usr.bin/find/Makefile
/usr/src/usr.bin/find/function.c
/usr/src/usr.bin/find/getdate.y
/usr/src/usr.bin/find/find.h
/usr/src/usr.bin/find/find.core
/usr/src/usr.bin/find/main.c
/usr/src/usr.bin/find/find.1
/usr/src/usr.bin/find/operator.c
/usr/src/usr.bin/find/misc.c
/usr/src/usr.bin/find/option.c
/usr/src/usr.bin/find/ls.c
$ with exec flag
$ find /usr/src/usr.bin/find -exec pwd \;
find: .: Permission denied
/usr/home/notroot/testfind
/usr/home/notroot/testfind
/usr/home/notroot/testfind
/usr/home/notroot/testfind
/usr/home/notroot/testfind
/usr/home/notroot/testfind
/usr/home/notroot/testfind
/usr/home/notroot/testfind
/usr/home/notroot/testfind
/usr/home/notroot/testfind
/usr/home/notroot/testfind
/usr/home/notroot/testfind
/usr/home/notroot/testfind
/usr/home/notroot/testfind
/usr/home/notroot/testfind

I think the warning here is now superfluous, but I kept it as I thought some might be used to seeing this as a fatal, and it might be less arresting to lower to a warning level error as opposed to removing it as an error condition all together.

Patch attached with submission follows:

Index: function.c
===================================================================
--- function.c	(revision 232929)
+++ function.c	(working copy)
@@ -644,7 +644,8 @@
 		/* NOTREACHED */
 	case 0:
 		/* change dir back from where we started */
-		if (!(plan->flags & F_EXECDIR) && fchdir(dotfd)) {
+		if (!(plan->flags & F_EXECDIR) && !(ftsoptions&FTS_NOCHDIR)
+			&& fchdir(dotfd)) {
 			warn("chdir");
 			_exit(1);
 		}
Index: find.c
===================================================================
--- find.c	(revision 232929)
+++ find.c	(working copy)
@@ -179,7 +179,7 @@
 
 	tree = fts_open(paths, ftsoptions, (issort ? find_compare : NULL));
 	if (tree == NULL)
-		err(1, "ftsopen");
+		err(1, "fts_open");
 
 	for (rval = 0; (entry = fts_read(tree)) != NULL;) {
 		if (maxdepth != -1 && entry->fts_level >= maxdepth) {
Index: main.c
===================================================================
--- main.c	(revision 232929)
+++ main.c	(working copy)
@@ -63,7 +63,7 @@
 
 time_t now;			/* time find was run */
 int dotfd;			/* starting directory */
-int ftsoptions;			/* options for the ftsopen(3) call */
+int ftsoptions;			/* options for the fts_open(3) call */
 int isdeprecated;		/* using deprecated syntax */
 int isdepth;			/* do directories on post-order visit */
 int isoutput;			/* user specified output operator */
@@ -150,8 +150,10 @@
 		usage();
 	*p = NULL;
 
-	if ((dotfd = open(".", O_RDONLY, 0)) < 0)
-		err(1, ".");
+	if ((dotfd = open(".", O_RDONLY, 0)) < 0) {
+		warn(".");
+		ftsoptions |= FTS_NOCHDIR;
+	}
 
 	exit(find_execute(find_formplan(argv), start));
 }


>Release-Note:
>Audit-Trail:

From: Matthew Story <matthewstory@gmail.com>
To: freebsd-gnats-submit@freebsd.org
Cc:  
Subject: Re: bin/166056: [patch][bin] find fails with .: permission denied,
 even when using absolute paths
Date: Tue, 13 Mar 2012 15:19:42 -0400

 --20cf307cfd98b5c98204bb24bd10
 Content-Type: text/plain; charset=ISO-8859-1
 
 On Tue, Mar 13, 2012 at 3:08 PM, Matthew Story <matthewstory@gmail.com>wrote:
 
 > >Fix:
 > apply patch (patch was made against -CURRENT).  patch will warn if it
 > cannot open ".", and set the FTL_NOCHDIR flag before proceeding, below
 > cases demonstrate functionality with&without the -exec flag
 >
 
 Embarrassingly enough, my patch breaks -execdir ... I will follow-up with a
 correction that doesn't break -execdir.  Apologies for not being more
 thorough in my testing.
 
 -- 
 regards,
 matt
 
 --20cf307cfd98b5c98204bb24bd10--

From: Matthew Story <matthewstory@gmail.com>
To: freebsd-gnats-submit@freebsd.org
Cc:  
Subject: Re: bin/166056: [patch][bin] find fails with .: permission denied,
 even when using absolute paths
Date: Wed, 14 Mar 2012 03:06:48 -0400

 --20cf307ca01a78e21704bb2e9e78
 Content-Type: multipart/alternative; boundary=20cf307ca01a78e21204bb2e9e76
 
 --20cf307ca01a78e21204bb2e9e76
 Content-Type: text/plain; charset=ISO-8859-1
 
 On Tue, Mar 13, 2012 at 3:19 PM, Matthew Story <matthewstory@gmail.com>wrote:
 
 > On Tue, Mar 13, 2012 at 3:08 PM, Matthew Story <matthewstory@gmail.com>wrote:
 >
 >> >Fix:
 >> apply patch (patch was made against -CURRENT).  patch will warn if it
 >> cannot open ".", and set the FTL_NOCHDIR flag before proceeding, below
 >> cases demonstrate functionality with&without the -exec flag
 >>
 >
 > Embarrassingly enough, my patch breaks -execdir ... I will follow-up with
 > a correction that doesn't break -execdir.  Apologies for not being more
 > thorough in my testing.
 >
 
 I have resolved the -execdir issue with my patch, and also resolved an
 issue with -execdir not functioning properly with the -L option, as
 FTS_LOGICAL sets FTS_NOCHDIR during fts_open(3):
 
 from: libc/gen/fts.c
  145     /* Logical walks turn on NOCHDIR; symbolic links are too hard. */
  146     if (ISSET(FTS_LOGICAL))
  147         SET(FTS_NOCHDIR);
 
 It also sets FTS_NOCHDIR if it cannot open "." O_RDONLY.  the man-page for
 fts is silent on these two issues, I'll file a separate PR to document that.
 
 There also seems to be an issue with find -execdir ... {} + wherein it
 executes with cwd of the last entry (if plan->e_ppos is maxed out), or with
 wd of the find process (if called by finish_execplus), my expectation for
 this behavior would be to execute with arguments grouped by parent
 directory.  I preserved the existing behavior, as it is not as trivial as
 fixing the -L behavior ... I will open another PR for this behavior.
 
 new patch attached, viewable via http here:
 
 http://axe0.blackskyresearch.net/patches/matt/find.no_dotfd.patch.txt
 
 
 
 -- 
 regards,
 matt
 
 --20cf307ca01a78e21204bb2e9e76
 Content-Type: text/html; charset=ISO-8859-1
 Content-Transfer-Encoding: quoted-printable
 
 On Tue, Mar 13, 2012 at 3:19 PM, Matthew Story <span dir=3D"ltr">&lt;<a hre=
 f=3D"mailto:matthewstory@gmail.com">matthewstory@gmail.com</a>&gt;</span> w=
 rote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
 =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 <div class=3D"im">On Tue, Mar 13, 2012 at 3:08 PM, Matthew Story <span dir=
 =3D"ltr">&lt;<a href=3D"mailto:matthewstory@gmail.com" target=3D"_blank">ma=
 tthewstory@gmail.com</a>&gt;</span> wrote:</div><div class=3D"gmail_quote">=
 <div class=3D"im">
 <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
 x #ccc solid;padding-left:1ex">
 
 &gt;Fix:<br>
 apply patch (patch was made against -CURRENT). =A0patch will warn if it can=
 not open &quot;.&quot;, and set the FTL_NOCHDIR flag before proceeding, bel=
 ow cases demonstrate functionality with&amp;without the -exec flag<br></blo=
 ckquote>
 
 <div><br></div></div><div>Embarrassingly enough, my patch breaks -execdir .=
 .. I will follow-up with a correction that doesn&#39;t break -execdir. =A0A=
 pologies for not being more thorough in my testing.</div></div></blockquote=
 >
 <div><br></div><div>I have resolved the -execdir issue with my patch, and a=
 lso resolved an issue with -execdir not functioning properly with the -L op=
 tion, as FTS_LOGICAL sets FTS_NOCHDIR during fts_open(3):</div><div><br>
 </div><div>from: libc/gen/fts.c</div><div>=A0145 =A0 =A0 /* Logical walks t=
 urn on NOCHDIR; symbolic links are too hard. */</div><div>=A0146 =A0 =A0 if=
  (ISSET(FTS_LOGICAL))</div><div>=A0147 =A0 =A0 =A0 =A0 SET(FTS_NOCHDIR);</d=
 iv><div><br></div>
 <div>It also sets FTS_NOCHDIR if it cannot open &quot;.&quot; O_RDONLY. =A0=
 the man-page for fts is silent on these two issues, I&#39;ll file a separat=
 e PR to document that.</div><div><br></div><div>There also seems to be an i=
 ssue with find -execdir ... {} + wherein it executes with cwd of the last e=
 ntry (if plan-&gt;e_ppos is maxed out), or with wd of the find process (if =
 called by finish_execplus), my expectation for this behavior would be to ex=
 ecute with arguments grouped by parent directory. =A0I preserved the existi=
 ng behavior, as it is not as trivial as fixing the -L behavior ... I will o=
 pen another PR for this behavior.</div>
 <div><br></div><div>new patch attached, viewable via http here:</div><div><=
 br></div><div><a href=3D"http://axe0.blackskyresearch.net/patches/matt/find=
 .no_dotfd.patch.txt">http://axe0.blackskyresearch.net/patches/matt/find.no_=
 dotfd.patch.txt</a><br>
 </div></div><br><br clear=3D"all"><div><br></div>-- <br>regards,<br>matt<br=
 >
 
 --20cf307ca01a78e21204bb2e9e76--
 --20cf307ca01a78e21704bb2e9e78
 Content-Type: text/plain; charset=US-ASCII; name="find.no_dotfd.patch.txt"
 Content-Disposition: attachment; filename="find.no_dotfd.patch.txt"
 Content-Transfer-Encoding: base64
 X-Attachment-Id: f_gzs0yp900
 
 SW5kZXg6IGZ1bmN0aW9uLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gZnVuY3Rpb24uYwkocmV2aXNpb24gMjMy
 OTUwKQorKysgZnVuY3Rpb24uYwkod29ya2luZyBjb3B5KQpAQCAtNTAsNiArNTAsNyBAQAogI2lu
 Y2x1ZGUgPGRpcmVudC5oPgogI2luY2x1ZGUgPGVyci5oPgogI2luY2x1ZGUgPGVycm5vLmg+Cisj
 aW5jbHVkZSA8ZmNudGwuaD4KICNpbmNsdWRlIDxmbm1hdGNoLmg+CiAjaW5jbHVkZSA8ZnRzLmg+
 CiAjaW5jbHVkZSA8Z3JwLmg+CkBAIC01OTUsNyArNTk2LDcgQEAKIGludAogZl9leGVjKFBMQU4g
 KnBsYW4sIEZUU0VOVCAqZW50cnkpCiB7Ci0JaW50IGNudDsKKwlpbnQgY250LCBwYXRoX2ZkOwog
 CXBpZF90IHBpZDsKIAlpbnQgc3RhdHVzOwogCWNoYXIgKmZpbGU7CkBAIC02NDQsOSArNjQ1LDMx
 IEBACiAJCS8qIE5PVFJFQUNIRUQgKi8KIAljYXNlIDA6CiAJCS8qIGNoYW5nZSBkaXIgYmFjayBm
 cm9tIHdoZXJlIHdlIHN0YXJ0ZWQgKi8KLQkJaWYgKCEocGxhbi0+ZmxhZ3MgJiBGX0VYRUNESVIp
 ICYmIGZjaGRpcihkb3RmZCkpIHsKLQkJCXdhcm4oImNoZGlyIik7CisJCWlmICghKHBsYW4tPmZs
 YWdzICYgRl9FWEVDRElSKSAmJiBcCisJCSAgICAhKHRyZWUtPmZ0c19vcHRpb25zICYgRlRTX05P
 Q0hESVIpICYmIFwKKwkJICAgIGZjaGRpcihkb3RmZCkpIHsKIAkJCV9leGl0KDEpOworCQkvKiAK
 KwkJICogaWYgbm8gZW50cnksIHdlIGFyZSBmaW5pc2hpbmcuIHdpdGhvdXQgRl9OT0NIRElSIHRo
 aXMgd291bGQKKwkJICogaGFwcGVuIHRvIGJlIGluIHB3ZCwgc28gZG9uJ3QgY2hkaXIuIFdlIHVz
 ZSB0cmVlLT5mdHNfb3B0aW9ucworCQkgKiBpbnN0ZWFkIG9mIGZ0c29wdGlvbnMsIGFzIEZUU19M
 T0dJQ0FMIHNldHMgRlRTX05PQ0hESVIgb24KKwkJICogZnRzX29wZW4oMykKKwkJICovCisJCX0g
 ZWxzZSBpZiAoZW50cnkgIT0gTlVMTCAmJiBlbnRyeS0+ZnRzX2xldmVsID4gMCAmJiBcCisJCSAg
 ICAocGxhbi0+ZmxhZ3MgJiBGX0VYRUNESVIpICYmIFwKKwkJICAgICh0cmVlLT5mdHNfb3B0aW9u
 cyAmIEZUU19OT0NIRElSKSkgeworCQkJLyogCisJCQkgKiAiVHJ1bmNhdGUiIGJ5IE5VTCBhdCBu
 YW1lIGJvdW5kYXJ5LCB3ZSBjYW5ub3QgdXNlCisJCQkgKiBlbnRyeS0+ZnRzX3BhcmVudCBoZXJl
 IGFzIGl0IGlzIG5vdCByZWxpYWJseSBzZXQKKwkJCSAqIHVubGVzcyB3ZSBoYXZlIGNhbGxlZCBm
 dHNfY2hpbGRyZW4oMyksIHdoaWNoIHdlIGhhdmUKKwkJCSAqIG5vdC4KKwkJCSAqLworCQkJZW50
 cnktPmZ0c19wYXRoW2VudHJ5LT5mdHNfcGF0aGxlbiAtIGVudHJ5LT5mdHNfbmFtZWxlbl0gPSAn
 XDAnOworCQkJaWYgKChwYXRoX2ZkID0gb3BlbihlbnRyeS0+ZnRzX3BhdGgsIE9fUkRPTkxZLCAw
 KSkgPCAwIFwKKwkJCSAgICB8fCBmY2hkaXIocGF0aF9mZCkgfHwgY2xvc2UocGF0aF9mZCkpIHsK
 KwkJCQl3YXJuKCJjaGRpciIpOworCQkJCV9leGl0KDEpOworCQkJfSAKIAkJfQogCQlleGVjdnAo
 cGxhbi0+ZV9hcmd2WzBdLCBwbGFuLT5lX2FyZ3YpOwogCQl3YXJuKCIlcyIsIHBsYW4tPmVfYXJn
 dlswXSk7CkluZGV4OiBmaW5kLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gZmluZC5jCShyZXZpc2lvbiAyMzI5
 NTApCisrKyBmaW5kLmMJKHdvcmtpbmcgY29weSkKQEAgLTE3OSw3ICsxNzksNyBAQAogCiAJdHJl
 ZSA9IGZ0c19vcGVuKHBhdGhzLCBmdHNvcHRpb25zLCAoaXNzb3J0ID8gZmluZF9jb21wYXJlIDog
 TlVMTCkpOwogCWlmICh0cmVlID09IE5VTEwpCi0JCWVycigxLCAiZnRzb3BlbiIpOworCQllcnIo
 MSwgImZ0c19vcGVuIik7CiAKIAlmb3IgKHJ2YWwgPSAwOyAoZW50cnkgPSBmdHNfcmVhZCh0cmVl
 KSkgIT0gTlVMTDspIHsKIAkJaWYgKG1heGRlcHRoICE9IC0xICYmIGVudHJ5LT5mdHNfbGV2ZWwg
 Pj0gbWF4ZGVwdGgpIHsKSW5kZXg6IG1haW4uYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09
 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBtYWluLmMJKHJldmlz
 aW9uIDIzMjk1MCkKKysrIG1haW4uYwkod29ya2luZyBjb3B5KQpAQCAtNjMsNyArNjMsNyBAQAog
 CiB0aW1lX3Qgbm93OwkJCS8qIHRpbWUgZmluZCB3YXMgcnVuICovCiBpbnQgZG90ZmQ7CQkJLyog
 c3RhcnRpbmcgZGlyZWN0b3J5ICovCi1pbnQgZnRzb3B0aW9uczsJCQkvKiBvcHRpb25zIGZvciB0
 aGUgZnRzb3BlbigzKSBjYWxsICovCitpbnQgZnRzb3B0aW9uczsJCQkvKiBvcHRpb25zIGZvciB0
 aGUgZnRzX29wZW4oMykgY2FsbCAqLwogaW50IGlzZGVwcmVjYXRlZDsJCS8qIHVzaW5nIGRlcHJl
 Y2F0ZWQgc3ludGF4ICovCiBpbnQgaXNkZXB0aDsJCQkvKiBkbyBkaXJlY3RvcmllcyBvbiBwb3N0
 LW9yZGVyIHZpc2l0ICovCiBpbnQgaXNvdXRwdXQ7CQkJLyogdXNlciBzcGVjaWZpZWQgb3V0cHV0
 IG9wZXJhdG9yICovCkBAIC0xNTAsOCArMTUwLDEwIEBACiAJCXVzYWdlKCk7CiAJKnAgPSBOVUxM
 OwogCi0JaWYgKChkb3RmZCA9IG9wZW4oIi4iLCBPX1JET05MWSwgMCkpIDwgMCkKLQkJZXJyKDEs
 ICIuIik7CisJaWYgKChkb3RmZCA9IG9wZW4oIi4iLCBPX1JET05MWSwgMCkpIDwgMCkgeworCQl3
 YXJuKCIuIik7CisJCWZ0c29wdGlvbnMgfD0gRlRTX05PQ0hESVI7CisJfQogCiAJZXhpdChmaW5k
 X2V4ZWN1dGUoZmluZF9mb3JtcGxhbihhcmd2KSwgc3RhcnQpKTsKIH0K
 --20cf307ca01a78e21704bb2e9e78--

From: Matthew Story <matthewstory@gmail.com>
To: freebsd-gnats-submit@freebsd.org
Cc:  
Subject: Re: bin/166056: [patch][bin] find fails with .: permission denied,
 even when using absolute paths
Date: Wed, 14 Mar 2012 13:20:26 -0400

 --20cf307cfd46f9824a04bb373032
 Content-Type: text/plain; charset=ISO-8859-1
 
 On Wed, Mar 14, 2012 at 3:06 AM, Matthew Story <matthewstory@gmail.com>wrote:
 
 > On Tue, Mar 13, 2012 at 3:19 PM, Matthew Story <matthewstory@gmail.com>wrote:
 >
 >> On Tue, Mar 13, 2012 at 3:08 PM, Matthew Story <matthewstory@gmail.com>wrote:
 >>
 > It also sets FTS_NOCHDIR if it cannot open "." O_RDONLY.  the man-page for
 > fts is silent on these two issues, I'll file a separate PR to document that.
 >
 
 see: docs/166091
 
 --20cf307cfd46f9824a04bb373032--
>Unformatted:
