>>>>> " " == Paul Menage <email@example.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
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
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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.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