From owner-freebsd-hackers  Wed Apr  7  6:27:13 1999
Delivered-To: freebsd-hackers@freebsd.org
Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175])
	by hub.freebsd.org (Postfix) with ESMTP id 62377157E8
	for <hackers@freebsd.org>; Wed,  7 Apr 1999 06:26:41 -0700 (PDT)
	(envelope-from sheldonh@axl.noc.iafrica.com)
Received: from sheldonh (helo=axl.noc.iafrica.com)
	by axl.noc.iafrica.com with local-esmtp (Exim 2.12 #1)
	id 10UsJu-000E4g-00
	for hackers@freebsd.org; Wed, 7 Apr 1999 15:24:42 +0200
From: Sheldon Hearn <sheldonh@iafrica.com>
To: hackers@freebsd.org
Subject: misc/10700: find(1) and the current directory
Date: Wed, 07 Apr 1999 15:24:41 +0200
Message-ID: <54105.923491481@axl.noc.iafrica.com>
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


Hi folks,

I'm looking at PR 10700, which suggests a fix for a simple problem,
where a find is run as nobody from /usr/libexec/locate.updatedb (called
from /etc/periodic/weekly/310.locate) and blows if it can't fchdir to
root's homedir.

The fix suggested is a work-around. The real issue seems to lie within
an assumption made in find(1), namely that the current directory will
always be accessible.

That isn't true in a case like this (run as root):

	# cd /tmp
	# mkdir problem
	# chmod 700 problem
	# cd problem
	# echo find / | su -fm nobody

This doesn't work because find(1) always tries to open a file descriptor
for '.' (the current direcory) on startup. The only time this descriptor
might be used is for a fchdir after a fork, before an execvp (in support
of the -exec and -ok options).

So all I need now is some approach guidance. Where's the right
place to fix the reported bug?

a) In the way the periodic script calls locate.updatedb,
b) in the way locate.updatedb uses find, or
c) in find itself?

Thanks,
Sheldon.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message