>>>>> " " == Paul Menage <pmenage@ensim.com> writes:
> Is something like this more acceptable? It actually struck me
> how few fs-specific directory permission() methods there were
> in the tree - almost all directories leave it NULL and let
> vfs_permission() do the work. The only common place where this
> patch is potentially going to make a noticeable difference is
> the case of a non-root user accessing NFS. I'm not sure whether
> this is going to outweigh the cost of having to check two
> mostly-NULL methods instead of one, compared to just inlining
> vfs_permission().
The NFS permission method *will* change. Currently we violate the
NFSv3 specs when we call vfs_permission().
Ideally, the NFS permission method would be empty. There is little
point in doing any permissions checking before making another RPC call
--whether you do it using ACCESS or *NIX permission bits-- since
whatever you do will be prone to races. (BTW: that redundancy argument
also applies to things like doing lookup() before exclusive file
create etc...)
The only places where we would need to explicitly check access
permissions are when we do
- File open() without creation.
- Changing the current directory.
- Walking a pathname.
For the latter case, but not the former two, we definitely want to
cache the ACCESS RPC call results for efficiency.
Cheers,
Trond
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue May 07 2002 - 22:00:20 EST