Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 5 May 2003 12:42:50 +1000 (EST)
From:      Bruce Evans <bde@zeta.org.au>
To:        Kirk McKusick <mckusick@beastie.mckusick.com>
Cc:        Jens Schweikhardt <schweikh@FreeBSD.org>
Subject:   Re: Access times on executables (kern/25777) 
Message-ID:  <20030505113734.I6343@gamplex.bde.org>
In-Reply-To: <200305042351.h44Np2Th017215@beastie.mckusick.com>
References:  <200305042351.h44Np2Th017215@beastie.mckusick.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 4 May 2003, Kirk McKusick wrote:

> 	From: Bruce Evans <bde@zeta.org.au>
> ...
> 	This doesn't work unless the user has permission to change the atime
> 	using utimes(2) with a non-NULL times pointer.
> ...
> OK, so how about instead of use VOP_SETATTR, we just try to VOP_READ
> one byte of data. It will run with the speed of read (and indeed since
> we just mapped in the header above, the data should be in the cache).
> It has the benefit of speed and not requiring the user to own the file.
> It has the drawback of requiring that the file be readable though most
> executables are set to be readable.

It would work better than that.  VOP_READ() works right here since the
permissions checks are done at the vfs level at open(2) time, not on every
VOP_READ() or read(2).

I think VOP_SETATTR() should work similarly: do permissions checks at
the vfs level using VOP_ACCESS() instead of in every file system, so
that there is less duplicated code and the permissions checks don't
get in the way when you don't want them.  This change is now easy for
at least setting times.  In Lite2, ufs_setattr() had to dereference
`ip' for its permissions check for times, but this detail is now pushed
down to VOP_ACCESS() using the VADMIN flag.  There is a new reference
to `ip' for SF_SNAPSHOT, but this is unrelated to normal permissions
except it can cause EPERM to be returned for reasons not documented
in utimes.2.

Bruce



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030505113734.I6343>