From owner-freebsd-arch@FreeBSD.ORG  Fri May  9 21:47:42 2003
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id 249E337B401; Fri,  9 May 2003 21:47:42 -0700 (PDT)
Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 7B5D343F85; Fri,  9 May 2003 21:47:40 -0700 (PDT)
	(envelope-from bde@zeta.org.au)
Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246])
	by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id OAA24636;
	Sat, 10 May 2003 14:47:25 +1000
Date: Sat, 10 May 2003 14:47:24 +1000 (EST)
From: Bruce Evans <bde@zeta.org.au>
X-X-Sender: bde@gamplex.bde.org
To: Brian Buhrow <buhrow@lothlorien.nfbcal.org>
In-Reply-To: <200305091732.h49HW9x11035@lothlorien.nfbcal.org>
Message-ID: <20030510142105.H2968@gamplex.bde.org>
References: <200305091732.h49HW9x11035@lothlorien.nfbcal.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
cc: arch@FreeBSD.org
cc: Jens Schweikhardt <schweikh@FreeBSD.org>
cc: Kirk McKusick <mckusick@beastie.mckusick.com>
Subject: Re: Access times on executables (kern/25777)
X-BeenThere: freebsd-arch@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Discussion related to FreeBSD architecture
	<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 10 May 2003 04:47:42 -0000

On Fri, 9 May 2003, Brian Buhrow wrote:

> 	I hope you forgive my naive question, but I fail to understand how the
> NFS case can fail under any circumstance.  If a user tries to execute an
> nfs-mounted binary which is not readable by him, doesn't the system "read"
> the binary as the user root in order to execute the program, assuming the
> proper execute bit is set?  And, once that is done, wouldn't the system
> continue to read (page) that file as root?  If that doesn't work, then I

This lets the VOP_READ() method but not the VOP_SETATTR() method work.
For both methods, we have a readable vp which corresponds to a readable
fd in userland.  This requires getting past the access checks on the
pathname to the file being executed.  The execute bit works like the
read bit in the context of exec() -- VOP_READ() doesn't check either and
its callers check the appropriate one.  The VOP_SETTATR() method needs
write access instead of read access, and it checks for this internally
so execve() can't just grant this access by not checking it.

Bruce