dvp...

[Robert Watson]

On Mon, 27 Jan 2003, Pawel Jakub Dawidek wrote:

> I was wondering why sometimes we can use dvp in mac functions and
> sometimes we got only file's vnode and no directory's vnode. 
> 
> For example we got dvp in: 
> 
> mac_*_check_vnode_delete()
> mac_*_check_vnode_link()
> 
> etc., but no in:
> 
> mac_*_check_vnode_access()
> 
> I could understand that there is no sense to put dvp in functions that
> operates on file descryptors, because in theory we can't find its
> directory, but access(2) operates on file name, so? 

In general, we've provided access to dvp where dvp was already available
as part of the context, or was needed specifically because the operation
is a directory operation.  Both _delete() and _link() are specifically
operations on directories, since they are namespace operations.  It is
true that access(2) operates on a path (due to the lookup) and a file, but
the bulk of the VOP_ACCESS() logic is applied based on the target vnode,
not the directory.  Right now, we treat access() in the same class of
"file operations that may occur along with a path lookup", so the lookup
is mediated by the series of _lookup checks, and the final operation on
the object is solely on the vnode.  This includes _chmod(), _chown(),
_chflags(), and so on.  These calls can occur, generally, on both a path
and a file descriptor.  Currently, the name lookup for the call into the
_access() entry point doesn't provide locked access to the parent
directory, and we'd have to change the namespace logic to do that.  I'm
willing to take that approach if we think it will have significant payoff
in terms of policy capability?  Unlike chmod(), which has an fchown(), an
faccess() or feaccess() seems less likely.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert at fledge.watson.org      Network Associates Laboratories




To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-discuss" in the body of the message