Bug 166056 - [patch][bin] find(1) fails with .: permission denied, even when using absolute paths
Summary: [patch][bin] find(1) fails with .: permission denied, even when using absolut...
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-03-13 19:10 UTC by Matthew Story
Modified: 2017-12-31 22:32 UTC (History)
0 users

See Also:


Attachments
file.diff (1.56 KB, patch)
2012-03-13 19:10 UTC, Matthew Story
no flags Details | Diff
find.no_dotfd.patch.txt (2.71 KB, text/plain; charset=US-ASCII)
2012-03-14 07:06 UTC, Matthew Story
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Matthew Story 2012-03-13 19:10:03 UTC
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.

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:
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 ...
Comment 1 Matthew Story 2012-03-13 19:19:42 UTC
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
Comment 2 Matthew Story 2012-03-14 17:20:26 UTC
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
Comment 3 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 08:01:33 UTC
For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped